HeapAlloc 持续上涨且 GC 后不回落才是内存泄漏真问题；需高频采样 runtime.ReadMemStats 抓趋势，结合 pprof 差分分析 inuse_objects 增长，并排查日志阻塞、cgo 卡住、net.Conn 未关闭等非代码泄漏源。
内存持续增长 ≠ 一定泄漏，但 HeapAlloc 不回落就是真问题
很多同学一看到 top 的 RSS 涨到 1.5GB 就慌，重启完发现又涨回来——结果查了半天是 HeapSys 高、HeapAlloc 却稳定在 8MB。这说明 Go 运行时没把空闲内存还给 OS，不是泄漏，只是“懒”。真正该盯死的指标只有一个：HeapAlloc（已分配且仍在使用的堆内存字节数）。它持续上涨、GC 后不回落，才代表对象被意外强引用，无法回收。
怎么用 runtime.ReadMemStats 快速抓趋势
高频采样比单次快照有用得多。每秒调一次 runtime.ReadMemStats，记录 HeapAlloc、NumGC、NextGC，画成折线图，三类异常模式立刻浮现：
-
HeapAlloc稳步爬升，每次 GC 后只回落一点点 → 全局 map 忘记delete、日志缓冲区无限追加、goroutine 闭包捕获了大结构体 -
NumGC几乎不动，但HeapSys和HeapInuse持续扩大 → 可能是GODEBUG=madvdontneed=1关闭了主动释放，或 runtime 认为空闲页不够多，暂不归还；也可能是大量小对象导致碎片，回收后仍占大片虚拟地址空间 -
NextGC缓慢增大，但HeapInuse增速更快 → 新分配远超回收能力，大概率是热点路径频繁make([]byte, ...)或json.Marshal，要用go tool pprof --alloc_space定位
注意：每次必须传新 runtime.MemStats{} 变量，别复用指针，否则字段值会污染。
为什么 pprof heap 有时看不出泄漏
因为泄漏对象可能只占总堆的 0.3%，在 inuse_space 视图里藏得极深。单看一个快照，就像找一根针掉进草垛——得用时间差放大问题：
- 先抓一个基线：
wget http://localhost:6060/debug/pprof/heap -O before.out - 跑 10 分钟业务（比如压测接口），再抓一个：
wget ... -O after.out - 本地对比：
go
→ pprof 会自动计算差异，高亮增长最多的 allocation site
tool pprof -http=:9999 before.out after.out
重点看 inuse_objects（存活对象数）是否也在涨——如果对象数不变但单个变大，可能是缓存膨胀；如果对象数涨了，大概率是 goroutine 泄漏或 timer 未 stop。
排查常被忽略的“非代码”泄漏源
很多内存暴涨根本不是变量没释放，而是底层系统资源卡住，逼 Go runtime 不断开新线程、申请新内存：
-
日志文件写入阻塞：自研日志库若用同步os.File.Write+fsync，磁盘慢时每次写都触发阻塞系统调用，runtime 会新建 OS 线程执行，线程不退出，其栈和关联内存就一直挂着 -
cgo 调用未返回：比如调用了 C 的加密函数或数据库驱动，内部卡在锁或网络等待，Go 会为其绑定专用线程，且不会回收 -
net.Conn没Close：虽然读写是非阻塞的，但连接本身持有 fd、接收缓冲区、TLS 状态等，不关就会累积；尤其http.Client默认复用连接，若response.Body忘记Close()，底层连接池不会释放它
检查当前线程数：cat /proc/$(pidof yourapp)/status | grep Threads。如果长期 >50，且 goroutine 数不高，基本可锁定是阻塞系统调用惹的祸。
最麻烦的是那种“半泄漏”：对象逻辑上该释放了，但某个地方悄悄存了引用，比如 context.WithValue 传了个大结构体，下游又塞进全局 map；或者 defer 里写了 defer log.Info(data)，而 data 是个 MB 级切片——defer 会捕获变量值，生命周期直接延长到函数结束。这种细节，光看代码很难揪，必须靠 pprof 差分 + ReadMemStats 趋势双验证。
