pprof HTTP 接口需显式启用并启动服务，仅导入 net/http/pprof 不生效；正确做法是导入 _ "net/http/pprof" 并运行 go http.ListenAndServe("localhost:6060", nil)，且抓 heap 快照应避开 GC 干扰、两次采样对比、禁用 ?gc=1 参数。
pprof HTTP 接口必须显式启用，否则 profile 数据根本不会暴露
很多初学者以为只要 import net/http/pprof 就自动生效，其实不然——它只注册了 handler，但没启动 HTTP 服务，/debug/pprof/ 路径压根不可访问。最简启动方式是：
- 加一行
import _ "net/http/pprof" - 再起一个 goroutine：
go http.ListenAndServe("localhost:6060", nil)
注意：nil 作为 handler 是关键，它会让 net/http/pprof 的默认路由生效；如果用了自定义 http.ServeMux，就得手动调用 pprof.Handler("heap").ServeHTTP 或显式注册路由。
常见错误：只导入 runtime/pprof——它只能写文件，不提供 HTTP 接口；或者监听 0.0.0.0:6060 却没加防火墙或反向代理限制，线上等于裸奔。
抓 heap 快照要避开 GC 干扰，两次采样比单次更可靠
刚启动或 GC 频繁时抓的 /debug/pprof/heap 很可能全是临时对象，看不出真实泄漏。真正有效的做法是等服务稳定运行、负载平稳后，间隔 30–60 秒抓两次：
立即学习“go语言免费学习笔记（深入）”；
curl -s http://localhost:6060/debug/pprof/heap -o before.heap- 等够时间再跑：
curl -s http://localhost:6060/debug/pprof/heap -o after.heap
文件名必须带 .heap 或 .pb.gz 后缀，否则 go tool pprof 可能识别失败。绝对不要加 ?gc=1 参数——它强制 GC 后采样，会把本该存活的对象“刷掉”，掩盖泄漏。
验证是否抓准：用 go tool pprof before.heap 进入交互模式，输入 top，再切到 View → Sample，选 inuse_space；如果 alloc_space 远高于 inuse_space，说明分配快、释放也快，大概率不是泄漏。
pprof 输出里看到 runtime.mallocgc 占比最高，别慌——它只是入口，真凶在调用栈上层
runtime.mallocgc 出现在 top 列表第一位是必然的，它是所有内存分配的统一出口。真正要盯的是它的调用者——也就是谁在频繁调用 make、new、append，且分配的对象没被回收。
- 用
top -cum查累积分配量，而不是只看单层占比 - 再用
list your_package.(*YourStruct).Method定位到具体代码行，比如某行buf := make([]byte, 1024*1024)在循环里反复创建却没复用 - 重点排查三类高危模式：
http.HandlerFunc闭包捕获大结构体、sync.Map.LoadOrStore后不清理过期项、全局 slice 截取后底层数组被长期持有
如果调用栈里全是 runtime.selectgo 和 goroutine，说明泄漏藏在中间层——这时得点 web 图，在火焰图里逐层展开，找到业务函数名再 drill down。
本地复现时别只靠 HTTP 接口，关键路径手动打点更可控
线上环境受限多，本地调试反而可以更精准。比如在 handler 入口/出口、goroutine 启动前后，直接调用：
-
pprof.WriteHeapProfile(f)写入文件，比 HTTP 更确定时机 - 配合
runtime.GC()强制触发 GC 后再采样，排除短期对象干扰 - 用
go tool pprof -sample_index=alloc_space查分配总量，和-inuse_space对比，确认是否持续增长
容易忽略的一点：go tool pprof 默认显示 inuse_space（当前驻留），但泄漏常表现为 alloc_space 持续上涨——这个参数必须手动指定，否则可能漏掉缓慢累积型泄漏。
真实泄漏的判定标准很朴素：稳定负载下 HeapInuse 线性增长，重启归零复现；而不仅仅是“内存涨了”。工具只是放大镜，最终得靠你判断哪段代码不该长期持有哪些对象。
