真泄漏需满足HeapAlloc在稳定负载下线性增长、重启归零复现且GC后不回落；pprof排查须禁用?gc=1、文件名带.heap或.pb.gz、间隔≥30秒采样，再用pprof -http差分聚焦inuse_space定位泄漏源。
Go 程序“内存涨了”不等于泄漏，真泄漏得看 HeapAlloc 在 GC 后是否持续抬高；pprof 不是点开就灵，关键在采样时机、对比方式和指标选择。
怎么确认是真泄漏，而不是 runtime 没还内存给 OS
别信 top 或 ps 里的 RSS ——它包含大量 HeapIdle 和未归还的 mmap 区域，Go runtime 会按需保留这部分内存以减少系统调用开销。真正要盯的是 runtime.ReadMemStats 返回的 HeapAlloc：
- 每次调用必须传新
runtime.MemStats实例，复用会导致字段被覆盖 - 加个每秒打点循环：
log.Printf("HeapAlloc: %.2f MB", float64(ms.HeapAlloc)/1024/1024) - 观察空闲期：连续几次 GC 后
HeapAlloc只回落一点点，基线缓慢上移 → 高概率存在长期存活对象泄漏 - 典型诱因：
map[string]*BigStruct忘了delete、全局 channel 未关闭、timer/ticker 未Stop()
pprof 抓 heap 快照时为什么总看不到泄漏对象
/debug/pprof/heap 默认返回的是 inuse_space（当前存活对象），但很多泄漏对象本身不大，或藏在引用链深处，单次快照里占比极小。更有效的方式是差分分析：
- 先请求
http://localhost:6060/debug/pprof/heap?gc=1强制 GC 后采第一份（heap1.out） - 等 5–10 分钟，再抓第二份（
heap2.out） - 执行：
go tool pprof -base heap1.out heap2.out，进交互后输入top或top -cum - 重点关注高频分配路径：
bytes.makeSlice、runtime.malg、net/http.readRequest—— 它们不是泄漏源，而是泄漏前兆 - 若怀疑闭包捕获导致逃逸，用
-alloc_space替代默认指标：go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap
goroutine 泄漏常连带堆泄漏，怎么快速定位
每个 goroutine 至少占 2KB 栈空间，且若它持有堆对象（比如往全局 chan 塞 buffer），就会把整条引用链钉死。排查优先级应高于纯堆分析：
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.NumGoroutine()打点，看是否随时间线性增长 - 抓取
http://localhost:6060/debug/pprof/goroutine?debug=1，检查是否有大量 goroutine 卡在：chan receive、select、time.Sleep或net/http.(*conn).readRequest - 典型陷阱：
go func() { for range ch { ... } }()——ch永远不关，协程永不退出 - 修复原则：所有
go func()必须绑定context.Context，并在select中监听ctx.Done()；time.After创建的 timer 要显式Stop()
sync.Pool 用错反而加重泄漏，哪些操作必须避免
sync.Pool 不是通用缓存，它绕过 GC 扫描，一旦放进去的对象被错误持有，就会形成隐式泄漏：
- 禁止放入闭包、结构体指针、含指针字段的 map —— 它们捕获的外部变量会被一并冻结在堆上
- 禁止 Put 前不重置状态：比如
bytes.Buffer的buf字段不清空，下次 Get 出来仍带旧数据，可能引发逻辑错误或内存膨胀 - Pool 里对象不会出现在 heap profile 中，但它的
New函数若创建大底层数组（如过大的bytes.Buffer），仍会推高alloc_space - 安全使用范围：预分配的
[]byte、无指针字段的 struct、strings.Builder（需调用Reset()）
最隐蔽的泄漏点，往往不在报错日志里，而在闭包捕获变量逃逸后，又被全局 map 或长期存活的 goroutine 持有——它不 panic、不超时、不打印任何线索，只安静地把内存一寸寸吃掉。
