要用 pprof 抓真实 heap profile，需显式触发采样：线上启用 net/http/pprof 并访问 /debug/pprof/heap（不带 ?gc=1），本地在疑似泄漏点调用 pprof.WriteHeapProfile(f) 保存为 .heap 文件。
怎么用 pprof 抓到真实的 heap profile
Go 的 runtime/pprof 默认不自动采集堆内存快照，必须主动触发或开启持续采样。常见错误是只调用了 pprof.StartCPUProfile，却忘了堆 profile 需要显式调用 pprof.WriteHeapProfile 或通过 HTTP 接口访问 /debug/pprof/heap。
- 如果程序已上线，最稳妥方式是启用
net/http/pprof：在启动时加一行http.ListenAndServe("localhost:6060", nil)，然后用wget <a href="https://www.php.cn/link/ec8651f0e5217e642dfa7e7585f08e95">https://www.php.cn/link/ec8651f0e5217e642dfa7e7585f08e95</a>获取原始 profile 数据 - 本地复现问题时，可在疑似泄漏点前后手动调用
pprof.WriteHeapProfile(f)，注意文件需以.heap后缀保存，否则go tool pprof可能识别失败 - 不要用
?gc=1参数反复刷，它强制 GC 后采样，会掩盖真实存活对象；真正要看的是「GC 后仍没被回收」的内存，所以默认（不带参数）的/debug/pprof/heap更可信
top、list、web 这几个命令为什么结果对不上
go tool pprof 的不同视图展示逻辑不同，不是 bug，而是统计口径差异。比如 top 默认按「当前存活对象总大小」排序，而 list funcName 显示的是该函数分配的所有内存（含已被 GC 回收的），web 图则只画出调用栈中 still-in-use 的部分。
-
top输出里看到某个结构体占 200MB，但list里找不到对应分配点？大概率是该结构体由第三方库创建，你代码里只存了指针，真正分配发生在底层 map/slice 初始化或 json.Unmarshal 过程中 -
web图里出现大量runtime.mallocgc直接连到main.main？说明主 goroutine 在持续新建对象且没释放引用，重点检查全局 map、slice append、闭包捕获变量等场景 - 使用
pprof -http :8080 xxx.heap时，浏览器打开后默认是「inuse_space」视图；想看累计分配量，得点右上角「View」→「Allocation space」，否则会漏掉高频小对象分配问题
哪些典型代码模式会导致 heap profile 看起来“正常”但实际泄漏
堆 profile 显示 inuse_space 稳定，不代表没泄漏。Go 的 GC 能回收大部分对象，但以下情况会让对象长期驻留，profile 却不突兀：
- 全局
sync.Map或普通map[string]*BigStruct持续写入不清理：key 不重复时，内存只增不减；profile 里表现为runtime.mapassign下游的类型持续增长 - Goroutine 泄漏 + channel 缓冲区未消费：
ch := make(chan *Data, 1000)被发满后阻塞，发送方 goroutine 挂起并持有所有已发送对象的引用，这些对象无法被 GC - 使用
bytes.Buffer或strings.Builder做长周期拼接，内部底层数组不断扩容但从未重置，Reset()被忽略 - Context 被意外传给长期运行的 goroutine（如后台定时任务），导致其携带的 value（比如 trace span、auth token）永远无法释放
为什么本地跑不出线上 heap 增长，但 pprof 又没报错
线上和本地的 GC 行为受 GOGC、内存压力、goroutine 数量影响极大。GOGC=100（默认）时，当新分配内存达到上次 GC 后存活内存的 2 倍才触发 GC；如果线上流量大、对象生命周期长，GC 间隔拉长，heap 就容易「缓慢爬升」，而本地压测时间短、GC 频繁，根本压不出问题。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
runtime.ReadMemStats的Alloc字段判断泄漏：它包含已分配但尚未 GC 的内存，波动大；应关注HeapInuse和HeapObjects的长期趋势（比如每小时采一次，看是否单调上升） - 线上环境务必设置
GODEBUG=gctrace=1观察 GC 日志，重点关注scvg（内存回收）是否频繁失败，以及每次 GC 后heap_alloc是否未回落到基线 - 用
go tool pprof -base baseline.heap current.heap做差分分析，比单独看单个 profile 更容易定位新增的保留集（retained set）
pprof 不是万能的，它只能告诉你「谁分配了内存」，不能直接说「谁让内存无法释放」；真正难的是顺着引用链往上翻——哪个 map 没删 key，哪个 channel 没关，哪个 context 没 cancel。这些细节藏在业务逻辑里，不在堆栈上。
