pprof 默认看不到内存泄露，因其 /debug/pprof/heap 返回的是当前存活对象快照（inuse_space），而泄露本质是累计分配量（alloc_space）持续增长；需用 -alloc_space 分析、对比 heap diff、检查 goroutine 泄露，并结合逃逸分析与 runtime.MemStats 验证。
pprof 为什么默认看不到内存泄露？
因为 pprof 的 /debug/pprof/heap 默认返回的是「当前存活对象」的快照（即 heap profile），不是分配总量。内存泄露通常表现为对象持续分配却从不释放，所以光看实时堆快照可能一片风平浪静——泄露对象被反复新建又丢弃引用，但新对象不断顶上，老对象早被 GC 掉了。
真正该盯的是「累计分配量」：它不关心是否还活着，只统计程序启动以来所有 new、make、append 等触发的堆分配字节数。泄露往往藏在分配速率长期偏高、且与业务吞吐不匹配的地方。
- 用
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap查累计分配（不是默认的-inuse_space） - 采样前先让服务稳定运行几分钟，避免冷启动噪声干扰
- 如果
alloc_space图谱里某函数长期占总分配 20%+，且该函数本不该高频分配（比如只是做状态检查），就要怀疑它在无意中构造大对象或闭包捕获了大结构体
如何复现并锁定泄露点？
单纯看 pprof 报告容易误判——你看到的「高分配函数」可能是无辜的中间层，真正的泄露源头在它调用链更深处，或者在 goroutine 泄露导致对象无法 GC。
- 开启 goroutine profile：
curl http://localhost:6060/debug/pprof/goroutine?debug=2，检查是否有数量持续增长、状态为runnable或syscall的 goroutine（比如忘了close的 channel 导致range卡住） - 对比两个时间点的 heap profile：先
curl -s "http://localhost:6060/debug/pprof/heap?debug=1" > heap1.txt，等 30 秒再采一次heap2.txt，然后go tool pprof -base heap1.txt heap2.txt，看 diff 出的新分配热点 - 注意
runtime.mallocgc在 top 列表里频繁出现，说明底层分配密集，但真正要追的是它的调用者，不是它自己
常见踩坑：GC 假象和逃逸分析误导
Go 的 GC 是并发三色标记，不是每次分配都立刻回收。一个对象如果在栈上能被证明生命周期明确，编译器会做逃逸分析把它留在栈上——这种不会进 heap profile，自然也不会出现在 pprof 里。但一旦它“逃逸”到堆，就进入监控范围。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
go build -gcflags="-m -l"检查关键函数里变量是否逃逸：如果看到... escapes to heap，而这个变量是个大 struct 或 slice，就要确认它是否真的需要长期持有 - 不要依赖
runtime.GC()强制触发来“清理假泄露”：pprof 分析的是真实分配行为，手动 GC 只是加速回收，掩盖不了分配逻辑本身的问题 - HTTP handler 里用
defer resp.Body.Close()是基础，但更隐蔽的是：把resp.Body赋值给一个全局 map 或未关闭的 channel，会导致整个响应体（可能几 MB）一直被引用
pprof 之外必须做的两件事
pprof 是利器，但不是全知之眼。它看不到 Go runtime 外部的资源泄漏（比如 Cgo 调用 malloc 后没 free），也看不到因 GC 压力过大导致的 STW 时间飙升——后者得靠 /debug/pprof/gc 和 runtime.ReadMemStats 配合看。
- 在关键路径加
runtime.ReadMemStats(&ms); log.Printf("HeapAlloc: %v, NumGC: %v", ms.HeapAlloc, ms.NumGC)，观察HeapAlloc是否随请求线性上涨、NumGC是否异常频繁（比如 1 秒内几十次） - 如果用了
cgo，必须单独检查 C 侧内存：用valgrind --tool=memcheck ./your-binary（Linux）或 Xcode Instruments（macOS），Go 的 pprof 对这部分完全无感
最麻烦的泄露往往不在代码里，而在你信任的第三方库悄悄缓存了什么东西，又没提供清除接口——这时候得靠 pprof 的 symbolization + 源码交叉定位，而不是指望一键诊断。
