真内存泄漏的关键特征是HeapInuse和HeapAlloc在稳定负载下线性增长且重启后复现；需间隔30秒以上连续采样3–5次堆快照，用pprof分析inuse_space趋势，并排除cgo、unsafe、runtime底层等pprof不可见场景。
怎么确认 Go 程序真有内存泄漏
“内存一直在涨”不等于泄漏——Go 有 GC，很多上涨是 GC 滞后、缓存未淘汰、或对象本就该活很久。真泄漏的关键特征是：runtime.ReadMemStats 返回的 HeapInuse 和 HeapAlloc 在稳定负载下随时间线性增长，且每次重启后归零、再次复现。
- 别在程序刚启动时采样：GC 还没稳，
MemStats.NextGC接近MemStats.HeapAlloc时抓的 profile 基本无效 - 至少间隔 30 秒以上，连续抓 3–5 次堆快照，看
inuse_space趋势是否持续抬升 - 用
go tool pprof -http=:8080 <binary> heap.pprof打开后，在右上角 SAMPLE 下拉菜单选inuse_space（不是alloc_objects） - 如果
alloc_space远大于inuse_space，说明分配多、释放少，更可能是泄漏；若两者接近，大概率是长生命周期对象（比如全局 map 缓存）
pprof 抓不到泄漏？这些地方它根本看不见
pprof.WriteHeapProfile 只记录当前存活对象，但有些泄漏它完全不感知——因为 runtime 根本没把它当“Go 对象”管。
- cgo 分配的 C 堆内存：比如
C.malloc、C.CString，pprof不统计，得加GODEBUG=cgocheck=2运行看 panic，再用valgrind --tool=memcheck（Linux）验证 -
unsafe.Pointer或reflect绕过类型系统持有的内存，pprof 无法追踪引用链 - netpoll、timer、workergoroutine 内部结构（如
netpollfd表），属于 runtime 底层，不在堆 profile 覆盖范围内 - goroutine 泄漏常连带堆泄漏：每个泄漏 goroutine 分配一个 buffer 并塞进全局 channel，
runtime.NumGoroutine()持续上升就是强信号
怎么用 pprof 抓到真实、可比对的 heap profile
默认不启用 net/http/pprof，pprof.WriteHeapProfile 又容易被忽略调用时机，导致抓的全是“假平静”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 线上服务必须启用
net/http/pprof：导入_ "net/http/pprof"，再起个 goroutine 调用http.ListenAndServe("localhost:6060", nil) - 抓 profile 优先走 HTTP 接口：
wget http://localhost:6060/debug/pprof/heap -O before.heap，比WriteHeapProfile更实时、更全 - 本地复现时，别只抓一次：在疑似泄漏点前、中、后各调一次
pprof.WriteHeapProfile(f)，文件名务必以.heap结尾，否则go tool pprof可能识别失败 - 对比要用
diff：比如go tool pprof -http=:9999 before.heap after.heap，浏览器里直接看新增的inuse_space分配路径
基准测试里怎么让内存数据可比、不骗人
testing.B 默认不管 GC，B.ReportAllocs() 的 allocs/op 在短函数里波动极大，根本没法横向比较。
立即学习“go语言免费学习笔记（深入）”；
- 在
B.ResetTimer()前手动触发 GC：runtime.GC(); runtime.GC()（两次确保 STW 完成），再开始计时 - 用
-benchmem -memprofile=mem.out生成 profile，然后go tool pprof -alloc_space mem.out查累计分配量——这个比allocs/op稳定得多 - 别只信 top 函数：重点看
list <funcname>输出里哪几行反复分配，尤其是闭包捕获变量、往全局 map/slice append、或 channel recv 后没处理完就丢弃
真正难的不是工具怎么用，而是区分“GC 没来得及”和“永远不释放”——前者看趋势是否收敛，后者看重启后是否复现。很多泄漏藏在 timer.Reset、context.WithCancel 未 cancel、或者 defer 里忘了 close file/rows 这些不起眼的地方。
