要让pprof真正暴露瓶颈，需确保：1. 下划线导入触发init注册；2. HTTP服务已启动且路由带尾部斜杠；3. CPU采样期间程序真实执行计算；4. 内存分析区分/heap与/allocs；5. 交互中优先用top/list/peek定位热点；6. 生产环境隔离监听地址并限频；7. 离线场景用runtime/pprof手动写文件；8. 注意编译内联导致函数名丢失。
怎么让 pprof 真正暴露瓶颈，而不是返回空 profile？
pprof 不是“开了就灵”的开关——它只反映你让它采集的内容。如果 http://localhost:6060/debug/pprof/profile?seconds=30 返回空或卡住，大概率不是工具坏了，而是服务根本没在采样。
- 必须确保
import _ "net/http/pprof"在main包中执行（下划线导入触发init注册），且 HTTP server 已启动并监听对应端口 - 若用自定义
http.ServeMux，不能只注册/debug/pprof，必须带尾部斜杠：/debug/pprof/（否则子路径如/debug/pprof/heap404） - CPU profile 默认采样 30 秒，期间程序得真正在跑计算逻辑；如果这 30 秒里程序大部分时间在
select{default:}或time.Sleep，采样结果会严重失真——几乎全是 runtime.idle - 内存 profile（
/heap）默认只抓当前存活对象（in-use），查泄漏要配合/allocs看累计分配量，二者语义完全不同
go tool pprof 交互时，哪些命令能快速定位真实热点？
进到 go tool pprof 交互终端后，别急着 web 火焰图——先用轻量命令筛出关键函数。
-
top：看 CPU 时间占比最高的前 10 个函数（注意单位是“采样数”，非绝对毫秒） -
list：比如list http.ServeHTTP，直接显示该函数内各行代码的采样分布，精准到行号 -
peek：查看调用该函数的上游路径，快速判断是哪条业务链路引来的压力 -
web启动本地可视化后，火焰图里宽而高的函数块才是真瓶颈；窄而高的通常是 runtime 开销（如调度、GC），优先级低于业务函数
线上环境怎么安全开 pprof，又不被扫端口拖垮服务？
生产环境暴露 /debug/pprof/ 是高危操作，但完全关掉又失去应急能力。折中方案不是“加个密码”，而是控制面+数据面分离。
