应抓两次间隔2–5分钟的heap快照并用-base对比，禁用?gc=1，确保导入_net/http/pprof_且在ListenAndServe前注册，查看inuse_space趋势而非单次top，文件须以.heap或.pb.gz为后缀。
线上服务内存持续上涨，go tool pprof 抓出来的 /debug/pprof/heap 快照却看不出明显泄漏点？问题大概率出在采样方式、视图选择或解读逻辑上——不是 profile 没用，而是你没看到它真正想说的。
怎么触发一次靠谱的 heap profile 采样
别等 OOM 才动手。真实泄漏往往在业务低峰期或增长刚露头时就已开始积累，这时抓两次快照（间隔 2–5 分钟）比单次“大 dump”更有价值。
- 必须导入
_ "net/http/pprof"，且在http.ListenAndServe之前执行；漏掉下划线或顺序错，路由根本不会注册 - 访问
/debug/pprof/heap（不带?gc=1）——这是关键：默认路径反映的是「GC 后仍驻留」的对象，才是泄漏本体；?gc=1强制 GC 后采样，会把本该活着的对象“刷掉”，掩盖问题 - 如果程序没开 HTTP 服务，临时加一行
go http.ListenAndServe("127.0.0.1:6060", nil)即可，端口不冲突就不影响主逻辑 - 容器环境记得暴露端口：
-p 6060:6060，否则宿主机连不上
为什么 top 看不到你的函数名
top 输出里全是 runtime.makeslice、fmt.Sprintf、encoding/json.unmarshal，你的业务函数名压根不出现？这不是工具失灵，是逃逸和调用链遮蔽了源头。
- 高频小对象（比如反复
make([]byte, 1024)或拼接字符串）往往由标准库函数分配，但调用栈里有线索——用list fmt.Sprintf查看谁调用了它 -
list报 “no source found”？编译时用了-ldflags="-s -w"去符号了，得去掉才能定位到具体行号 - 真正分配动作可能发生在 map 赋值、channel send、闭包捕获变量等隐式场景，
web火焰图里若看到main.main → runtime.mallocgc直连，重点查全局map、未消费的缓冲 channel、或长期存活的 goroutine
inuse_space 和 allocation_space 到底该看哪个
浏览器打开 pprof -http :8080 xxx.heap 默认是 inuse_space 视图，但它只显示当前存活对象总大小——对查泄漏有用，但对查“高频小对象爆炸式分配”完全失效。
立即学习“go语言免费学习笔记（深入）”；
- 怀疑某接口一调用就分配一堆小结构体？切到右上角
View → Allocation space，这里统计的是「所有堆分配总量」，不管对象是否还活着 -
inuse_objects配合inuse_space一起看：如果对象数涨得猛但单个很小（比如struct{}），大概率是map或sync.Map无节制写入、key 不重复但 value 持续变大 -
/debug/pprof/allocs接口专为查分配热点设计，不受 GC 影响，适合定位瞬时高压力分配点；但它噪声大，得结合diff对比才有效
runtime.MemProfileRate 设置不当的典型后果
这个参数控制堆采样频率，默认 512KB（每分配 512KB 记一次调用栈）。调它不如调采样时机，但设错会直接废掉分析结果。
- 设成
0：采样关闭，WriteHeapProfile写出的文件内容为空——别信文档里“全量采集”的旧说法，Go 早就不支持了 - 设成
1：每字节都采样，CPU 和内存开销飙升，线上绝对禁用，本地调试也慎用 - 设成
1024或2048：适合高吞吐服务，降低开销，但可能漏掉短命小对象的分配模式；真要盯细节，不如多抓几个时间点快照做差分
最常被忽略的一点：profile 文件必须以 .heap 后缀保存，否则 go tool pprof 可能识别失败或加载错误视图。
