小对象逃逸主因是编译器逃逸分析判定其地址被返回、传入interface{}或被闭包捕获，强制堆分配；用go build -gcflags="-m"可验证，输出“moved to heap”即确认逃逸。
runtime.MemProfile 能抓到泄漏，但光靠它定位不到根因——真正卡住排查进度的，往往是逃逸分析没做、sync.Pool 用错、或全局 map 没清理。
为什么小对象会逃逸到堆上？
编译器不是凭感觉决定变量放栈还是堆，而是靠逃逸分析。一旦变量地址被返回、传给 interface{}、或被闭包捕获，就大概率逃逸。
常见触发点：
-
return &x：哪怕x是 int 或小 struct，只要取地址并返回，就逃逸 -
fmt.Printf("%v", x)：x被转成interface{}，逃逸 -
go func() { use(x) }()：闭包捕获局部变量，x 逃逸
验证方式很简单：go build -gcflags="-m" main.go。输出里出现 ... moved to heap 就是逃逸了。别信“它很小，应该在栈上”这种直觉。
sync.Pool 复用对象时的三个典型误用
sync.Pool 不是万能缓存，它只在 GC 前清空，且不保证复用——对象可能被随意丢弃，也可能被重复分配。
容易踩的坑：
- 把带状态的对象放进
Pool：比如已写入部分数据的bytes.Buffer，下次取出直接用，结果残留旧内容 - 没重置就复用：从
Pool.Get()拿出对象后，必须显式清空字段或调用Reset()（如buf.Reset()） - 在 goroutine 退出前没放回：对象只在当前 goroutine 的本地池里，不放回等于白建 Pool
正确姿势是：Get → Reset → Use → Put。漏掉 Reset 比不 Put 更危险。
全局 map 和切片不清理 = 内存缓慢上涨
很多人以为“GC 会回收”，但只要 key 还在全局 map 里，value 就永远可达。这不是 GC 失效，是引用链没断。
典型场景：
- HTTP handler 中往全局
cache map[string]*Response写，但从不删过期项 - 日志聚合中不断 append 到全局
buffer []byte，也不 truncate 或重置 - 用
sync.Map当无界缓存，没配驱逐策略
解决不是靠“等 GC”，而是主动控制生命周期：加 TTL、用 LRU、定期清理 goroutine、或改用带容量限制的 channel + worker 模式替代无界累积。
pprof 差分分析时忽略 inuse_space 增长速率
看 /debug/pprof/heap 快照，不能只盯着 top 函数。关键要看 inuse_space 随时间的增长斜率是否收敛。
实操建议：
- 采样间隔至少 5 分钟，连续采 3–5 次，用
go tool pprof -base heap1.pb.gz heap2.pb.gz差分 - 重点关注 diff 后
inuse_objects和inuse_space正向 delta 最大的类型，不是 alloc 最多的 - 如果
*http.Request或[]uint8持续增长，大概率是 handler 没关Body或没限 body size
差分结果里“+10MB inuse”比“alloc 100MB total”更能说明泄漏——后者可能是正常高频分配，前者才是真驻留。
真正难的不是发现内存涨了，而是确认某个变量到底该不该活那么久。逃逸分析输出、Pool 复用逻辑、map 生命周期管理，这三处一松懈，监控曲线就悄悄往上走。
