不能。pprof仅提供内存分配快照或持续分配数据，不直接标记泄露；需通过对比多次heap采样中持续增长且未释放的对象，结合调用栈回溯到具体代码行，并依赖未strip符号的构建才能显示行号。
pprof 能直接显示内存泄露的代码行吗
不能。pprof 本身不标记“泄露”，它只展示某一时刻的内存分配快照（heap）或持续分配行为（allocs）。所谓“定位泄露”，本质是通过对比多个采样点，识别出持续增长且未被释放的对象，再结合调用栈回溯到具体代码行。
关键前提：你的程序必须在运行中开启 pprof HTTP 接口，并确保 GC 已充分触发（否则缓存对象会干扰判断）。
如何抓取真正有用的 heap profile
直接访问 /debug/pprof/heap 默认返回的是「当前存活对象」的堆快照（即经过 GC 后仍驻留的内存），这才是排查泄露的核心依据。但很多人误用 /debug/pprof/allocs——它记录所有分配（含已回收），无法反映真实泄露。
- 启动时加
net/http/pprof：确保有http.ListenAndServe("localhost:6060", nil) - 等程序运行稳定、业务流量进入后，手动触发 GC：
runtime.GC()（或 curlhttp://localhost:6060/debug/pprof/gc） - 立刻抓取：
curl -o heap.pb.gz "http://localhost:6060/debug/pprof/heap?debug=1" - 避免在刚启动或低负载时采集——此时堆小、噪声大
用 go tool pprof 分析时最关键的三个命令
拿到 heap.pb.gz 后，别急着看火焰图。先用文本模式确认增长趋势和调用栈深度：
-
go tool pprof -http=:8080 heap.pb.gz：启动 Web 界面，但默认展示的是「总分配量」，要手动切换到 Inuse Objects 或 Inuse Space（这才是存活对象） -
go tool pprof -top heap.pb.gz：输出按内存占用排序的函数列表，重点关注inuse_space列，找持续增长的包/函数 -
go tool pprof -focus="YourPackage.*" -lines heap.pb.gz：加-lines才能显示具体行号；-focus过滤你关心的模块，避免被标准库调用栈淹没
注意：-lines 依赖编译时未 strip 符号（即默认构建即可），若用 go build -ldflags="-s -w" 会丢失行号信息。
为什么看到某行反复出现，却不是泄露源头
常见陷阱：pprof 显示 json.Unmarshal 占用高，但实际泄露来自你把反序列化后的 struct 存进了全局 map 且 never 删除。pprof 只告诉你“谁分配了内存”，不告诉你“谁持有引用”。
- 检查所有全局变量、缓存（
sync.Map、lru.Cache）、长生命周期 channel 的 receiver goroutine - 用
go tool pprof -alloc_space对比两次采样：如果某函数的alloc_space增长远高于inuse_space，说明它分配频繁但对象大多被释放——不是泄露点 - 真正泄露点往往伴随「调用栈深、路径固定、对象类型一致」，比如总是
new(MyStruct)出现在第 42 行，且该 struct 字段含map或slice未清理
最易忽略的一点：pprof 的堆采样是概率性的（默认 512KB 分配才采样一次），极小对象或高频小分配可能完全不出现在 profile 中——这时得结合 runtime.ReadMemStats 监控 HeapInuse 趋势，再针对性加日志或用 go tool trace 查 goroutine 持有关系。
