真泄漏必须满足HeapInuse和HeapAlloc在稳定负载下线性增长且重启归零复现；需避开GC频繁期采样，通过pprof差分inuse_space定位净增长对象，并排除cgo、unsafe、goroutine泄漏等pprof不可见场景。
怎么确认是内存泄漏而不是GC延迟或缓存常驻
Go 的 GC 不会实时回收，所以“内存涨了”不等于泄漏。真泄漏必须满足两个硬条件：HeapInuse 和 HeapAlloc 在稳定负载下随时间线性增长，且服务重启后归零、再次复现。
别在刚启动或 MemStats.NextGC 接近 MemStats.HeapAlloc 时采样——这时 GC 正疯狂 sweep，数据失真。建议等服务运行 5 分钟以上、流量平稳后再动手。
- 用
runtime.ReadMemStats打点记录，每 30 秒抓一次，画出HeapInuse曲线；若斜率持续为正，才值得深挖 -
alloc_space远大于inuse_space→ 分配多、释放少，倾向泄漏；两者接近 → 更可能是长生命周期对象（比如全局map或缓存） - 容器 RSS 持续上涨但
HeapInuse平稳？那大概率是 cgo 分配、unsafe持有或 runtime 底层结构（如 netpoll 表），pprof 看不见
为什么只看 heap topN 找不到泄漏点
泄漏对象在 inuse_space 中占比往往极小，一眼扫过去全是主逻辑函数，根本看不出异常。靠“谁占得多”找泄漏，在真实场景中基本失效。
必须做至少两次间隔 30 秒以上的采样，用 diff 对比净增长部分：
立即学习“go语言免费学习笔记（深入）”；
- 抓快照：
wget http://localhost:6060/debug/pprof/heap?inuse_space -O before.heap，等 30–60 秒再抓after.heap - 对比命令：
go tool pprof -http=:9999 -base before.heap after.heap - 浏览器打开后，右上角
SAMPLE切换为inuse_space，点View → Difference，只看新增路径 - 重点盯调用链末尾是业务代码、中间夹着
(*ConnPool).reaper、timerproc、select或chan receive的路径——它们往往是泄漏入口
goroutine 泄漏为什么总拖垮内存
每个 goroutine 默认栈 2KB，看似不多，但它只要活着，就可能“钉住”大对象：闭包捕获含 []byte 的 struct、channel 接收者一直挂着 map 引用、context.WithCancel 后没 cancel……这时 heap profile 里看不到泄漏源头，因为 GC 不敢动。
- 立刻访问
/debug/pprof/goroutine?debug=2（不是?debug=1），拿到完整调用栈 - 搜索关键词：
chan receive、select、time.Sleep、http.Transport、semacquire - 特别注意重复出现的业务文件行号（如
client.go:72），若某函数启动上千 goroutine 且状态全是IO wait，大概率是未关闭 channel 或 HTTP client 缺超时 - 用
runtime.NumGoroutine()打点监控，突增就是强信号；测试可用goleak.VerifyNone(t)捕获残留 goroutine
pprof 抓不到的泄漏类型和应对方式
pprof 只统计 Go 堆上的对象，以下几类它完全不感知：
- cgo 分配：如
C.malloc、C.CString—— 加GODEBUG=cgocheck=2运行，看是否 panic；Linux 下用valgrind --tool=memcheck -
unsafe.Pointer或reflect绕过类型系统持有的内存 —— 静态扫描 + 人工 review，尤其注意syscall、unsafe.Slice调用 - netpoll、timer、worker goroutine 内部结构 —— 这些属于 runtime 底层，不在堆 profile 覆盖范围，需结合
go tool trace查调度事件 - 文件句柄、数据库连接、Redis client —— 用
lsof -p $PID查 fd 数，确认sql.DB.SetMaxOpenConns、redis.Client.Close()是否漏调
最易被忽略的是：泄漏常藏在“看起来很安全”的地方——比如 ticker 忘记 Stop()、HTTP client 没设 Timeout、defer 里 close 错误地放在了错误分支。
