真泄漏需满足HeapInuse在稳定负载下线性增长且重启复现；否则多为GC滞后或长生命周期对象，应通过连续3–5次间隔≥30秒的pprof采样比对inuse_space趋势，并排除cgo、unsafe及runtime底层泄漏。
Go 程序内存“一直在涨”不等于泄漏；真泄漏必须满足两个硬条件：稳定负载下 runtime.MemStats.HeapInuse 持续单向增长，且重启后复现。否则大概率是 GC 滞后、缓存未淘汰或对象本就该活久一点。
怎么确认是内存泄漏，而不是 GC 没来得及回收？
别靠肉眼盯进程 RSS 或 top 的 RES 值——这些包含 mmap、cgo、runtime 底层结构，和 Go 堆无关。关键看 runtime.ReadMemStats 返回的原始指标：
-
HeapInuse（已分配且正在使用的堆内存）必须在稳定请求压测下线性上升，比如每分钟涨 2MB，持续 5 分钟以上 - 连续采样 3–5 次堆快照，间隔 ≥30 秒，用
go tool pprof -inuse_space对比，看同一类对象（如*http.Request或[]uint8）是否始终驻留、不回落 - 如果
alloc_objects远大于free_objects，说明对象分配多、释放少，泄漏嫌疑高；若两者接近，更可能是长生命周期缓存 - 手动触发
runtime.GC()后立刻抓 profile，能排除“GC 滞后”干扰——但注意：HTTP 接口默认不强制 GC，必须加?gc=1参数
pprof 抓 heap profile 为什么总是不准？
常见错误不是工具不行，而是没配对启动方式和采集路径：
- 线上服务必须显式启用 HTTP pprof：导入
_ "net/http/pprof"，再起 goroutine 调用http.ListenAndServe("localhost:6060", nil) - 本地复现时，
pprof.WriteHeapProfile(f)文件名必须以.heap结尾，否则go tool pprof无法识别 - 别只抓一次：在疑似泄漏点前、中、后各调一次
WriteHeapProfile，或用 HTTP 接口连续 wget：wget "http://localhost:6060/debug/pprof/heap?gc=1" -O after.heap - 对比要用 diff 模式：
go tool pprof -http=:9999 before.heap after.heap，Web UI 里直接看新增 inuse_space 分配路径
哪些泄漏 pprof 根本看不见？
pprof 只统计 Go runtime 管理的堆对象，以下三类泄漏它完全不感知：
- cgo 分配的 C 堆内存：比如
C.malloc、C.CString，需加GODEBUG=cgocheck=2运行，看是否 panic，再用valgrind --tool=memcheck验证（Linux） -
unsafe.Pointer或reflect绕过类型系统持有的内存，pprof 无法追踪引用链 - netpoll、timer、worker goroutine 内部结构（如
netpollfd表），属于 runtime 底层，不在堆 profile 覆盖范围内
这类问题往往表现为 runtime.NumGoroutine() 持续上涨，同时 RSS 涨得比 HeapInuse 快得多——这时候要优先查 goroutine 泄漏，而不是堆。
goroutine 泄漏怎么快速定位？
goroutine 泄漏常被误判为内存泄漏，但它才是“内存缓慢上涨”的真正推手——每个泄漏 goroutine 都会钉住一堆大对象（比如闭包捕获了含 []byte 的结构体）：
- 查完整堆栈必须用
curl "http://localhost:6060/debug/pprof/goroutine?debug=2"，默认?debug=1只返回总数 - 重点盯状态为
chan receive、select、time.Sleep的 goroutine，数量随请求稳定增加就是强信号 - 所有
go func() { ... }()必须有明确退出路径：HTTP handler 中启动的 goroutine 要绑定req.Context()；for range ch前确保ch会被关闭；time.Ticker和time.Timer必须显式Stop() - 检查
sync.Map和普通map：用时间戳、UUID 当 key 却从不delete，等于自己造内存黑洞
最易忽略的是：goroutine 泄漏本身不占多少堆内存，但它让本该被 GC 的对象永远存活——所以排查时，runtime.NumGoroutine() 和 HeapInuse 要一起看，不能只盯一个。
