runtime.ReadMemStats 是唯一靠谱的起点，因其提供不受 GC 暂停干扰的真实堆快照；需配合 runtime.GC() 多轮采集 HeapAlloc 和 HeapObjects，并同步检查 NumGoroutine 才能可靠识别泄漏。
为什么 runtime.ReadMemStats 是唯一靠谱的起点
Go 没有像 Java 的 heap dump 或 Python 的 tracemalloc 那样开箱即用的内存泄漏检测机制。所有可靠的手动检测，都必须基于 runtime.ReadMemStats 获取的底层统计——它返回的是当前堆分配的真实快照，不受 GC 暂停或缓存干扰。别信第三方包封装的“自动检测”，它们只是对这个函数的薄包装，核心逻辑逃不开它。
常见错误是直接比对 Alloc 字段就下结论：比如两次调用差值大就喊“泄漏”。这完全忽略 GC 周期和对象生命周期。真正要盯的是 HeapAlloc 在**多次 GC 后是否持续增长**，且增长量与业务操作不成比例。
- 每次调用前务必先触发 GC：
runtime.GC()，否则ReadMemStats返回的可能是上一轮未回收的脏数据 - 至少采集 3 轮：GC → 读 stats → 执行待测逻辑 → GC → 读 stats → ……，单次对比毫无意义
- 关注
HeapAlloc和HeapObjects两个字段，前者看字节数是否漂移，后者看对象数量是否只增不减
怎么写一个最小可用的泄漏探测辅助函数
不要试图写通用框架，先解决“执行某段代码后内存是否异常上涨”这个具体问题。下面这个函数足够轻量、可嵌入任何测试，且避开常见陷阱：
func CheckLeak(t *testing.T, f func(), thresholdMB int) {
var before, after runtime.MemStats
runtime.GC()
runtime.ReadMemStats(&before)
f()
runtime.GC()
runtime.ReadMemStats(&after)
leakMB := int((after.HeapAlloc - before.HeapAlloc) / 1024 / 1024)
if leakMB > thresholdMB {
t.Errorf("possible memory leak: +%d MB (threshold %d MB)", leakMB, thresholdMB)
}
}使用场景很明确：在单元测试里包裹可疑逻辑，比如反复创建结构体、启动 goroutine 但没回收 channel、缓存未清理等。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
thresholdMB不是固定值，要根据被测逻辑预期内存占用设——比如一次 HTTP 请求预期 2MB，就设 5；若只是处理字符串，设 0.5 更合理 - 函数内部强制两次
runtime.GC()，确保前后状态干净，避免 GC 延迟导致误报 - 不打印完整
MemStats，只暴露关键差值，避免信息过载；真要深挖时再手动加fmt.Printf("%+v", after)
goroutine 泄漏比内存泄漏更隐蔽，怎么一起抓
很多“内存泄漏”其实是 goroutine 泄漏：goroutine 持有堆对象引用，导致对象无法被 GC。所以只看 HeapAlloc 不够，必须同步检查 Goroutines 数量。
修改上面的辅助函数，加一行对比：
// ... same before/after MemStats reads goroutinesBefore := runtime.NumGoroutine() f() runtime.GC() runtime.ReadMemStats(&after) goroutinesAfter := runtime.NumGoroutine() // then check both leakMB and (goroutinesAfter - goroutinesBefore)
典型泄漏模式：启动 goroutine 但没用 select + done 控制退出，或者 channel 写入无接收方导致永久阻塞。
- goroutine 差值 > 0 就值得警惕，哪怕只有 1 个——它可能永远卡住并持有大量内存
- 注意
runtime.NumGoroutine()包含系统 goroutine（如定时器、netpoll），所以差值应结合上下文判断；建议 baseline 测量空跑时的波动范围 - 如果怀疑 goroutine 泄漏，用
debug.ReadGCStats或 pprof 生成/debug/pprof/goroutine?debug=2快照比对更准
真实项目里最容易被忽略的三个细节
写完辅助函数不等于万事大吉。实际压测或长期运行时，以下三点常让结果失真：
- 测试环境启用了
GODEBUG=gctrace=1？它会额外分配 trace buffer，污染HeapAlloc数值，务必关闭 - 被测函数里用了
sync.Pool？Pool 的预分配行为会让首次调用后HeapAlloc突增，后续稳定——这不是泄漏，是正常缓存 warm-up，需跳过首轮数据 - 用了
unsafe.Pointer或 cgo？runtime.ReadMemStats不统计 C 堆内存，这类泄漏完全看不到，得靠valgrind或asan单独查
辅助函数只是第一道筛子，它告诉你“可能有问题”，而不是“这里一定泄漏”。最终定位还得靠 pprof 抓 heap profile，按 allocation space 或 inuse space 排序，再结合代码找源头。
