pprof不能直接指出哪行代码泄露内存，它只提供存活对象的堆快照或累计分配热点；需结合MemProfileRate调优、完整调用栈profile及go tool pprof交互分析（如web火焰图、focus过滤、call graph）才能定位到具体业务代码行。
pprof 能不能直接告诉你哪行代码泄露了内存
不能。pprof 本身不追踪单次内存分配的调用栈归属，它展示的是「当前存活对象的堆分配快照」或「历史累计分配热点」。真正能帮你定位到具体代码行的，是结合 runtime.MemProfileRate 调整采样精度 + pprof.Lookup("heap") 导出的带完整调用栈的 profile 数据，再配合 go tool pprof 的交互式火焰图或列表分析。
为什么 heap profile 看起来全是 runtime 和 reflect 的调用栈
这是默认采样率太低（MemProfileRate = 512KB）导致的典型现象：小对象分配被过滤，只剩大块内存（如切片底层数组、map bucket）的分配点，而这些往往在 runtime.mallocgc 或 reflect.makeSlice 等底层函数中触发，上层业务调用栈被截断。
- 把
MemProfileRate设为1（每分配 1 字节都记录）——仅限调试环境，会显著拖慢程序 - 启动时加
os.Setenv("GODEBUG", "madvdontneed=1")避免 Linux 下madvise干扰 heap profile 准确性 - 确保采集前已稳定运行足够久，且泄露已发生（比如 goroutine 数持续上涨、RSS 持续增长）
怎么用 go tool pprof 快速找到可疑的业务函数
拿到 heap.pb.gz 后，别直接 top，先用 web 或 peek 看调用链深度：
go tool pprof -http=:8080 ./myapp heap.pb.gz
在网页里点开最大的节点，看「flat」列（本层分配量）和「cum''列（包含子调用的总分配量）。重点找：
- 业务包名开头的函数（如
myproject/cache.(*Cache).Put），且flat > 0——说明该函数内直接 new/make 了未释放的对象 - 频繁出现在多条路径末端的结构体类型（如
*http.Request、*bytes.Buffer），顺着它的allocs调用栈往上翻，直到第一个业务函数 -
inuse_objects高但inuse_space低的函数——可能是大量小对象堆积（如未关闭的sql.Rows、未释放的sync.Pool获取对象）
goroutine 泄露常被误认为内存泄露，怎么区分
执行 curl http://localhost:6060/debug/pprof/goroutine?debug=2，如果返回里有几百上千个状态为 select 或 chan receive 的 goroutine，且它们都卡在你写的某个 channel 操作上（比如 select { case 但 <code>ch 永远没 close），那就是 goroutine 泄露。它不直接增加 heap 内存，但会拖垮调度器、间接导致 GC 压力上升、掩盖真实内存问题。
真正的内存泄露往往伴随 runtime.GC 调用频率下降（因为堆增长变慢）或 gc pause 时间异常拉长——这时候要回过头检查 heap profile 的 inuse_space 是否随时间线性增长，而不是只看某一次快照。
最麻烦的情况是：泄露来自第三方库的缓存逻辑，比如 github.com/xxx/client 内部用了未限制容量的 map[string]*bigStruct，这时 profile 里看到的顶层函数可能是 client.Do，但真正泄露点藏在它的私有方法里——得结合源码和 pprof 的完整调用栈逐层点进去确认。
