pprof是Go语言基于采样机制的性能分析工具，通过/debug/pprof/profile等HTTP端点触发CPU、内存、goroutine等不同维度的运行时数据采集，依赖精确的采样策略、符号表完整性和上下文比对才能准确定位瓶颈。
这不是语言学习技巧的问题——pprof 分析不靠“记忆单词”或“语法规则”，它靠的是对采样机制、指标语义和 Go 运行时行为的准确理解。把 pprof 当成外语来“学语法”，反而会错过最关键的上下文判断。
net/http/pprof 导入后暴露的每个 endpoint 都不是“词汇”，而是不同采样策略的开关：
-
/debug/pprof/profile→ CPU 采样（基于时间中断，只抓正在执行的 goroutine） -
/debug/pprof/heap?gc=1→ GC 后存活堆快照（不是“内存总量”，是泄漏嫌疑对象） -
/debug/pprof/goroutine?debug=2→ 全量 goroutine 栈（默认只显示 running/blocked，?debug=2才吐出 select/case/sleep 中的“静默堆积”）
你不需要背参数，但必须清楚：每个 URL 背后触发的是哪类事件、采样频率多少、是否受 runtime 控制开关影响。比如 /debug/pprof/block 默认永远返回空，除非代码里提前调用了 runtime.SetBlockProfileRate(1)；/debug/pprof/mutex 同理依赖 runtime.SetMutexProfileFraction(1)。
为什么火焰图里全是 runtime.futex 或地址（如 0x456789）
这不是符号表丢失就是二进制文件没带调试信息。
- go build 必须用原始源码编译，不能 strip 或加 -ldflags="-s -w"
- 分析命令必须显式传入可执行文件路径：go tool pprof ./myapp http://localhost:6060/debug/pprof/profile?seconds=30，只给 URL 或只给 .pb.gz 文件，函数名必然丢失
- 用 file ./myapp 和 readelf -S ./myapp | grep debug 确认符号段存在
采样时间太短或业务没在跑，就别怪 profile “不准”
/debug/pprof/profile 默认 30 秒，但前提是这 30 秒内程序真在干 CPU 工作。
- 如果服务大部分时间在等网络、chan recv、time.Sleep，采样到的全是 runtime.epollwait、runtime.gopark —— 这不是 bug，是事实
- 压测期间再采，或手动延长：go tool pprof -seconds 60 http://host:6060/debug/pprof/profile
- 浏览器点链接采样不可控，容易错过高负载窗口；一律用 curl + 命令行触发
内存泄漏排查时，别只看单次 /heap
- 默认 /debug/pprof/heap 返回的是 **累计分配量（alloc_space）**，高频 new + free 也会暴涨，不代表泄漏
- 真正要看的是 GC 后存活对象：/debug/pprof/heap?gc=1
- 至少采 2 次，用差分分析：go tool pprof -base heap1.pb.gz heap2.pb.gz，重点盯 inuse_space 是否持续增长
- 如果 strings.Builder.Write 或 encoding/json.(*encodeState).marshal 在 top 排前三，大概率是序列化/拼接没复用缓冲区
真正卡住人的从来不是“怎么点开火焰图”，而是采样前没确认目标场景、采样后没比对上下文、分析时没带上原始二进制。pprof 不输出结论，它只输出数据——而数据怎么读，取决于你是否知道那个 goroutine 正卡在 sync.RWMutex.RLock 底下等写锁释放，而不是真的“泄露”了。
立即学习“go语言免费学习笔记（深入）”；
