真泄漏需满足HeapInuse与HeapAlloc在稳定负载下线性增长且重启归零复现；抓heap profile须禁用?gc=1、文件名带.heap或.pb.gz后缀、间隔≥30秒采样，再用pprof -http差分聚焦inuse_space定位泄漏源。
Go 程序内存持续上涨，大概率不是泄漏，而是 GC 没来得及回收，或对象本该长期存活（比如缓存、连接池）。真泄漏必须满足两个硬条件：稳定负载下 HeapInuse 和 HeapAlloc 随时间线性增长，且重启后归零、再次复现。
怎么抓到有效的 heap profile
pprof 不会自动采样堆内存，不手动触发就什么也看不到。线上服务最稳的方式是提前启用 net/http/pprof，本地复现则需在关键路径前后调用 pprof.WriteHeapProfile(f)：
- 线上：启动时加
import _ "net/http/pprof"，再起个 goroutine 跑http.ListenAndServe("localhost:6060", nil)；然后用wget http://localhost:6060/debug/pprof/heap -O heap1.pprof抓快照 - 本地复现：文件名必须带
.heap后缀（如heap_before.heap），否则go tool pprof可能识别失败 - 别在程序刚启动或
MemStats.NextGC接近MemStats.HeapAlloc时采样——这时 GC 正疯狂干活，数据失真
为什么单看 topN 常常找不到泄漏点
泄漏对象在 -inuse_space 里占比往往极小，一眼扫过去全是业务主逻辑，根本看不出异常。靠“占比高”找问题，在真实泄漏场景中基本失效：
- 必须做至少两次采样（间隔 30 秒以上），用
-base参数对比：go tool pprof -http=:9999 -base heap1.pprof heap2.pprof - 浏览器打开后，SAMPLE 切换为
inuse_space，再点 “View → Difference” 才能看到净增长部分 - 重点关注调用链末尾是业务代码、但中间夹着
(*ConnPool).reaper、connectionOpener、timerproc这类 runtime 或第三方库函数的路径——它们往往是泄漏入口
goroutine 泄漏为什么总和内存泄漏绑在一起
每个 goroutine 默认栈 2KB，一旦泄漏，不仅本身占内存，还极可能持有 buffer、map、channel、context 等堆对象，形成连锁泄漏：
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.NumGoroutine()打点监控，或直接访问http://localhost:6060/debug/pprof/goroutine?debug=2查看全量栈 - 常见陷阱：
RedisClient.Close()漏调、*sql.DB未设SetMaxOpenConns+SetConnMaxLifetime、自定义time.Ticker未Stop() - 怀疑 cgo 时，加
GODEBUG=cgocheck=2运行，看是否 panic；Linux 下可辅以valgrind --tool=memcheck
pprof 抓到可疑对象后怎么定位代码位置
pprof 默认只显示调用栈顶层，而泄漏往往藏在中间层：比如 goroutine 持有 channel、timer、HTTP handler 闭包里捕获了大结构体：
- 你已发现
*model.Order占用 80%inuse_space，但调用栈只显示http.HandlerFunc.ServeHTTP——这说明它被 handler 闭包意外捕获了 - 用
go tool pprof -http=:8080 your_binary heap.pb.gz，进 Web UI 后点「Focus」输入*model.Order，再点「View → Call graph」看谁在new它且没释放 - 关键参数差异：
go tool pprof -inuse_space看当前驻留内存，-alloc_space看总分配量——泄漏必须看前者 - 如果调用栈里出现
runtime.gopark或runtime.selectgo，优先查 channel 缓冲区、未关闭的context.WithCancel、或忘记close()的管道
真正难的不是拿到 profile，而是读懂它——尤其是当泄漏路径穿过 runtime、标准库、第三方 SDK 时，调用链里夹着几个匿名函数和闭包，很容易误判源头。别跳过「Difference」视图，也别只信 top 输出；真正的问题，往往藏在增长量最小但生命周期最长的那个对象里。
