真实泄漏需满足稳定负载下HeapInuse/HeapAlloc线性增长且重启归零复现；确认方法是间隔30秒以上采样两次heap快照，用pprof -inuse_space对比diff，关注同一类结构体是否持续驻留及heap_objects净增长是否不回落。
Go 程序内存持续上涨、GC 频繁触发、STW 时间变长，大概率不是 GC 失效，而是代码在“悄悄囤货”——对象没被释放、goroutine 持有引用、切片底层数组未回收。优化重点不在调 GC 参数，而在控制分配和持有关系。
怎么确认真有内存泄漏而不是 GC 滞后
别只看 heap_inuse 一时高：GC 暂未运行时它必然涨。关键指标是两次采样间 heap_objects 的净增长量是否稳定上升，且 free_objects 不同步回升。
- 用
curl "http://localhost:6060/debug/pprof/heap?debug=1"查实时摘要，重点关注heap_alloc和heap_inuse的比值是否随请求线性爬升 - 间隔 30 秒以上抓两个
heap.pb.gz，用go tool pprof -inuse_space对比，看同一类结构体（如*UserCache）是否持续驻留 - 避免刚调
runtime.GC()就采样——大量临时对象还没来得及被标记，会干扰判断
sync.Pool 不是万能的，用错反而加重 GC 压力
sync.Pool 适合复用生命周期短、大小固定、构造开销大的对象（如 []byte、bytes.Buffer），但不适用于长期存活或状态复杂的结构体。
- 池中对象可能被 GC 清理掉，所以每次
Get()后必须检查是否为nil，不能假设一定有可用对象 - 如果
New函数返回的是带指针字段的大结构体，而你没重置其内部字段，下次Get()到的可能是“脏对象”，引发逻辑错误或隐式内存持有 - 不要把 map、slice 本身放进 pool —— 它们的底层数组仍可能被其他变量引用，导致无法回收
切片和 map 是最常被忽视的泄漏源
切片扩容后底层数组可能远大于当前长度；map 删除键后不收缩，且底层哈希表节点不会自动归还给 runtime。
立即学习“go语言免费学习笔记（深入）”；
- 对已知大小的数据，用
make([]T, 0, n)预分配容量，避免多次append触发扩容复制 - 需要截断切片时，用
s = s[:0]重置长度，但若后续不再使用原底层数组，应改用s = append([]T(nil), s...)强制分配新底层数组 - map 中大量删除键后，若不再插入，建议重建：
m = make(map[K]V, len(m))，再range复制有效项 - 全局 map 存储缓存时，务必加过期机制或用
sync.Map+ 定期清理 goroutine，否则 key 永远不释放
goroutine 泄漏往往伪装成内存泄漏
一个卡在 select 或 chan receive 的 goroutine，自身栈空间不大，但它持有的局部变量（比如大 buffer、闭包捕获的 struct）全堆上驻留，且永不释放。
- 用
curl "http://localhost:6060/debug/pprof/goroutine?debug=2"查看 goroutine 状态，若大量显示chan receive或select且数量随请求递增，基本可定性为泄漏 - 所有
go func() { ... }()必须有明确退出路径：要么监听ctx.Done()，要么用sync.WaitGroup等待，禁止裸奔 - HTTP handler 内启 goroutine，必须绑定
req.Context()；timer/ticker 用完必须调Stop()，否则 runtime 持有其回调闭包，连带捕获的所有变量都无法回收
真正难排查的从来不是“哪行代码分配了内存”，而是“谁还在强引用它”。pprof 的 -inuse_space 只告诉你对象在哪，调用栈里那个看似无害的 http.HandlerFunc.ServeHTTP 下面，可能藏着一个闭包，正死死攥着 10MB 的日志缓冲区不肯撒手。
