正确开启 heap profile 需下划线导入 net/http/pprof 并手动挂载到自定义 mux；生产绑定 0.0.0.0:6060 并限制访问；泄漏查 /heap?gc=1，高频分配查 /allocs；pprof 中用 top -cum、view Allocation space、list 定位热点；MemProfileRate 勿乱调，重在采样时机。
线上内存上涨不一定是泄漏，但 heap profile 采样方式错了就一定找不到根因。
怎么开 /debug/pprof/heap 接口才真正生效
不是导入 "net/http/pprof" 就完事——必须是 _ "net/http/pprof"，下划线不能漏，否则注册逻辑根本不会触发。HTTP server 启动前就得完成导入，Go 的 init 函数会自动往 http.DefaultServeMux 注册路由，但如果你用了自定义 mux（比如 gorilla/mux 或 chi），它不会自动挂载，得手动 handler := http.NewServeMux(); handler.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))。
端口暴露要小心：用 127.0.0.1:6060 本地调试没问题，但容器或远程机器调用会失败；生产环境建议绑定 0.0.0.0:6060 并配合防火墙或反向代理限制访问 IP。
抓 heap 还是 allocs？看你想解决什么问题
/debug/pprof/heap 抓的是 GC 后仍存活的对象快照，默认反映「长期驻留」状态；/debug/pprof/allocs 统计的是「所有堆分配总量」，不管对象是否已被回收。两者用途完全不同：
立即学习“go语言免费学习笔记（深入）”；
- 怀疑泄漏（如
runtime.MemStats.HeapInuse持续涨）→ 用/heap?gc=1（强制 GC 后采样） - GC 频繁、STW 时间突增 → 用
/allocs?seconds=30查高频小对象分配点（比如循环里make([]byte, 1024)） - 想对比趋势 → 先抓 baseline.pprof，压测/运行一段时间后再抓 after.pprof，用
go tool pprof -base baseline.pprof after.pprof看增长项
pprof 交互界面里最容易忽略的三个操作
进 go tool pprof heap.out 后默认显示 inuse_space，但这只告诉你“现在占多少”，不告诉你“谁在疯狂 new”。真正关键的操作是：
- 输入
top -cum：看累计分配量最大的调用链，而不是单看 flat 值 - 输入
view→Allocation space（不是 inuse）：查短命对象分配热点，比如fmt.Sprintf或strings.Builder.String()导致的字符串爆炸 - 输入
list 函数名定位具体行，但要注意：如果报no source found，说明编译时加了-ldflags="-s -w"去符号，得去掉才能看到源码上下文
runtime.MemProfileRate 不该乱调，时机比频率重要
runtime.MemProfileRate 控制堆采样粒度，默认 512KB —— 意思是每分配 512KB 记一次调用栈。设成 0 就彻底关掉采样；设成 1 是灾难级开销，线上绝对禁用。实际中很少需要改它，因为：
- 调低 Rate 不等于更准：可能把小对象分配模式淹没在噪声里
- 真正影响判断的是采样时机：OOM 前抓已晚，应在业务低峰期或内存曲线刚出现上升拐点时立刻抓两次，间隔 2–5 分钟
- 若程序没 HTTP 服务，可临时起个 goroutine：
go http.ListenAndServe("127.0.0.1:6060", nil)，只要端口不冲突，不影响主逻辑
最常被卡住的地方不是命令跑不通，而是分不清「分配多」和「释放慢」：前者看 /allocs + Allocation space 视图，后者盯 /heap?gc=1 + 多次快照对比。逃逸分析导致的堆分配也会出现在 profile 里，但它不等于 bug——得结合代码逻辑判断是否合理。
