真泄漏必须满足heapinuse和heapalloc在稳定负载下线性增长、重启归零复现且gc后不回落；需间隔≥30秒采样两次heap快照，用pprof差分inuse_space定位净增长对象，并排除cgo、unsafe、goroutine泄漏等pprof不可见场景。
怎么确认自己写的 Go 模块真在泄漏内存
别信“内存涨了就是泄漏”——Go 的 GC 会滞后，缓存会预热，HeapAlloc 刚启动飙升几分钟后稳住，大概率不是泄漏。真泄漏必须同时满足：稳定流量下 runtime.ReadMemStats 返回的 HeapInuse 和 HeapAlloc 线性增长；每次重启归零，相同流量下复现；GC 后 HeapInuse 不回落，甚至越 GC 越高。
实操建议：
- 写个简单 HTTP handler，每 10 秒调一次
runtime.ReadMemStats，把HeapInuse打点到日志或 Prometheus，跑 15 分钟以上看趋势 - 用
go tool pprof http://localhost:6060/debug/pprof/heap?debug=1抓两次快照（间隔 ≥30 秒），重点比对inuse_space差分，不是alloc_objects - 如果
alloc_space远大于inuse_space，说明分配多、释放少，更可疑；若两者接近，优先查长生命周期对象（比如全局sync.Map或缓存）
闭包、context.Value、全局 map 是高频泄漏源
框架本身不泄漏，泄漏的是你用框架时写的代码。HTTP handler 里一个闭包捕获了大结构体，中间件往 context.WithValue 塞了不可回收的资源，或者全局 sync.Map 里塞了 map[string]*User 却从不删过期项——这些都会让对象永远活在堆上。
常见错误现象：
- handler 函数里定义匿名函数并引用外部大变量（如整个 config struct），该闭包被注册为回调后长期存活
- 中间件中反复调用
ctx = context.WithValue(ctx, key, hugeObj)，但没配 cleanup 逻辑，hugeObj随请求链路一路传递、永不释放 - 用
sync.Map当缓存，只LoadOrStore不Delete，key 不去重、value 不清理，内存只增不减 -
json.Unmarshal直接解到map[string]interface{}或map[string]*T，反序列化出大量指针，又没做生命周期管理
pprof 抓不到的泄漏，得换工具和思路
pprof.WriteHeapProfile 只记录 Go 堆上存活对象，三类泄漏它完全看不见：cgo 分配的 C 堆内存（如 C.malloc）、unsafe.Pointer 绕过 GC 的引用、以及 runtime 底层结构（如 netpollfd 表、timer heap）。这时候 pprof 显示“一切正常”，但 RSS 持续上涨。
实操建议：
- 怀疑 cgo 问题，启动时加
GODEBUG=cgocheck=2，看是否 panic；Linux 下用valgrind --tool=memcheck验证 C 层内存 - 检查
runtime.NumGoroutine()是否持续上升——goroutine 泄漏常连带堆泄漏（比如每个 goroutine 分配 buffer 并发到全局 channel） - 用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2看阻塞 goroutine，重点关注select卡在无缓冲 channel、time.AfterFunc未 cancel、(*ConnPool).reaper类路径 - 避免在
MemStats.NextGC接近HeapAlloc时采样，此时 GC 正 sweep，profile 失真
线上模块自查 checklist
上线前或排查阶段，逐条核对以下点，比等告警更省事：
- 所有
http.Client是否设置了Timeout和Transport（尤其MaxIdleConns、MaxIdleConnsPerHost），没设等于连接池无限膨胀 - 所有
database/sql.DB是否调用了SetMaxOpenConns和SetMaxIdleConns，没设默认不限制 - 所有
time.Timer/time.Ticker是否在不用时Stop()，尤其在 error path 或 early return 前漏掉 - 所有
defer是否真正释放了资源（如file.Close()、rows.Close()），而不是只 defer 了一个空函数 - 所有 channel 操作是否配对：有
close(ch)就不该再往里 send；range channel 前确保 sender 一定 close，否则 goroutine 卡死
最易被忽略的是：泄漏往往不在主干逻辑，而在错误处理分支、超时路径、或兜底 fallback 里——那些“理论上不会走到”的代码，恰恰最可能漏 cleanup。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
