pprof 不是语法学习工具，而是用于定位内存持续上涨、OOM 或 GC 压力大时的泄漏代码路径；需通过强制 GC 采样（?gc=1）、指定二进制文件分析、对比快照差值，并结合 goroutine 分析识别闭包捕获、channel 阻塞或全局引用等隐式持有问题。
pprof 本身不是“语言学习瓶颈突破”工具，它只反映运行时行为；想靠它学会 Go 语法或并发模型是南辕北辙。它真正管用的场景只有一个：当你的 Go 程序内存持续上涨、OOM 或 GC 压力大时，快速定位到哪段代码在反复创建/持有对象。
为什么直接访问 /debug/pprof/heap 看到的数字总在涨
默认请求 http://localhost:6060/debug/pprof/heap 不触发 GC，返回的是「堆上所有已分配但尚未被复用的内存块」快照——包含大量刚分配完、还没轮到回收的临时对象（比如循环里 make([]byte, 1024)）。这不是泄漏，只是 GC 还没跑。
- 必须加
?gc=1参数强制 GC 后采样：curl -s "http://localhost:6060/debug/pprof/heap?gc=1" -o heap1.pb.gz - 两次采样间隔至少 30 秒，且程序要有真实内存压力（不能刚启动就抓）
- 对比用
go tool pprof -base heap0.pb.gz heap1.pb.gz，它标出的是「新增存活对象」来源，不是总量差值
go tool pprof 分析时函数名全是 runtime.mcall 或十六进制地址
这是因为 pprof 的 heap profile 只记录内存分配地址，不带符号表。没有二进制文件，它根本不知道 0x456789 对应你代码里的 main.ProcessRequest。
- 错误写法：
go tool pprof http://localhost:6060/debug/pprof/heap?gc=1 - 正确写法：
go tool pprof ./myapp http://localhost:6060/debug/pprof/heap?gc=1（./myapp是你编译出的可执行文件） - 如果用
go run启动，先go build -o myapp .，再运行./myapp &，最后用二进制分析 - 验证是否成功：进入交互后输
top，第一列应显示业务函数名，而非空白或 runtime 函数
内存涨得慢，但 goroutine 数量暴涨
很多“内存泄漏”其实是 goroutine 泄漏。一个活着的 goroutine 会“钉住”它闭包里引用的所有对象（比如含 []byte 的 struct、未关闭的 response.Body、全局 map），导致 GC 不敢回收——heap profile 里看不到这些对象的分配源头，但 /debug/pprof/goroutine?debug=2 会暴露阻塞点。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
?debug=2：它输出完整调用栈；?debug=1只给统计摘要，没用 - 重点搜
chan receive、select、semacquire、net/http.(*persistConn).readLoop这类阻塞态 - 重复出现的行号（如
client.go:72）就是高危点：可能是 HTTP client 没设超时、response.Body 没Close()、或无缓冲 channel 的发送方一直等待 - 若发现某 handler 启动了数百个状态为
IO wait的 goroutine，基本可断定是泄漏源头
测试阶段就 OOM，但 -memprofile 文件根本没生成
go test -memprofile=mem.out 默认只在测试结束时写一次快照。如果测试中途 OOM，进程崩溃，文件压根不会落地。
- 定位问题时加
-memprofilerate=1：每次分配都记录（仅限调试，上线前必须调高，比如1024*1024，否则性能暴跌） - 避免
os.ReadFile：它内部调用io.ReadAll，强制把整个文件加载进内存——500MB 日志 = 至少 500MB 连续堆内存 -
bufio.Scanner更隐蔽：默认最大 token 64KB，但遇到超长行会静默扩容 buffer，直到吃光内存 - 高频小对象（如循环中
make([]byte, 1024)）优先用sync.Pool复用
真正的难点不在怎么用 pprof，而在于看懂它给出的线索后，能准确识别出代码里那些隐式持有引用的地方：闭包捕获、channel 缓冲区积压、全局 map 忘记 delete、或是 defer 没清掉资源。这些地方，pprof 只负责指路，改代码还得你自己动手。
