结论：/debug/pprof/allocs 统计历史总分配量（含已回收对象），不能反映内存泄漏；查泄漏必须用 /debug/pprof/heap?gc=1 多次采样对比 inuse_space 增量，并提供原始二进制文件解析符号。
直接说结论：pprof 的 /debug/pprof/allocs 采样的是「历史总分配量」，不是内存泄漏指标；想查泄漏，必须用 /debug/pprof/heap?gc=1 对比多次快照，且必须带原始二进制文件解析符号。
为什么 /debug/pprof/allocs 看起来内存一直在涨
/debug/pprof/allocs 返回的是程序启动以来所有堆内存分配的累计样本（alloc_objects 和 alloc_space），哪怕对象已被 GC 回收，它也会计入。所以你看到 inuse_space 不变但 alloc_space 持续上涨，大概率只是高频小对象分配——比如字符串拼接、fmt.Sprintf、反复 make([]byte, n)。
常见误判场景：
- HTTP handler 里每次请求都
json.Marshal大结构体 →allocs爆涨，但实际没泄漏 - 日志模块频繁构造
fmt.Sprintf模板 → 分配多，GC 快，heap?gc=1却很干净 - 没加
?gc=1直接看/heap，把未复用的已回收内存块当成“存活”
如何正确采集内存泄漏证据
泄漏的本质是：GC 后仍有大量对象持续存活且数量/大小随时间增长。必须用 heap?gc=1 获取真实存活堆快照，并做差值分析。
立即学习“go语言免费学习笔记（深入）”；
实操步骤：
- 先触发一次 GC：
curl "http://localhost:6060/debug/pprof/heap?gc=1" -o heap_0.pb.gz - 让程序运行一段时间（比如处理 1000 次请求），再采第二次：
curl "http://localhost:6060/debug/pprof/heap?gc=1" -o heap_1.pb.gz - 用
go tool pprof -base heap_0.pb.gz heap_1.pb.gz查新增存活对象 - 重点关注
inuse_space增量中占比高的函数，而非alloc_space
注意：-base 参数必须是更早的快照，否则差值方向反了；若提示 failed to fetch base profile，说明两个文件不是同个进程、同个二进制生成的。
go tool pprof 解析不出函数名的三大原因
火焰图或 top 输出全是 runtime.mcall、0x456789 或空白行？不是 pprof 失效，是符号缺失。
-
没传二进制文件：仅
go tool pprof http://...是错的，必须go tool pprof ./myapp http://...；go run启动的服务要先go build -o myapp . -
编译时 strip 了符号：避免用
go build -ldflags="-s -w"，调试阶段保留 DWARF 信息 -
用了自定义 http.ServeMux 但没注册 pprof 路由：下划线导入
_ "net/http/pprof"只向http.DefaultServeMux注册；若用了http.NewServeMux()，需手动挂载：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))
阻塞与锁分析必须显式开启
/debug/pprof/block 和 /debug/pprof/mutex 默认返回空，因为 Go 运行时默认关闭这两类采样以减少开销。
要在代码中提前启用：
- 阻塞分析（channel recv/send、锁等待、timer.Sleep）：
runtime.SetBlockProfileRate(1)，设为 1 表示每个阻塞事件都采样 - 互斥锁竞争分析：
runtime.SetMutexProfileFraction(1)，同样设为 1 才能捕获全部锁事件 - 这两个调用建议放在
init()或main()开头，且仅在需要分析时开启——长期开启会影响性能
验证是否生效：访问 http://localhost:6060/debug/pprof/block，若返回非空文本（含 chan receive、sync.(*Mutex).Lock 等栈帧），说明已采集到数据。
最常被忽略的一点：pprof 不是“看一眼就出答案”的工具，它输出的是采样统计，不是全量 trace。同一个问题，用 allocs 看是高频分配，用 heap?gc=1 对比却是稳定值——这意味着你该优化分配频率，而不是怀疑泄漏。
