pprof 默认返回 alloc_objects（含已回收对象），无法反映真实泄漏；必须用 ?gc=1 强制 GC 后采样 inuse_objects，再通过多次快照 diff 定位持续增长的存活对象及持有栈。
pprof 能发现内存泄漏，但不会自动告诉你“哪行代码漏了”——它只暴露现象，定位根因得靠你比对快照、读堆栈、查引用链。
为什么 /debug/pprof/heap 看起来“没泄漏”，实际却在涨内存
默认访问 /debug/pprof/heap 返回的是**分配总量（alloc_objects）**，包含已 GC 回收的对象。内存持续上涨但这里数字稳定？说明不是分配多，而是对象没被回收。
- 必须加
?gc=1参数，强制触发一次 GC 后再采样，得到的是当前存活对象的快照 - 单次快照意义有限，要对比：比如每 5 分钟抓一次
/debug/pprof/heap?gc=1，用go tool pprof加载多个文件做 diff - 注意：
go tool pprof -inuse_objects比-alloc_objects更适合查泄漏，它统计的是当前堆上存活的对象数
goroutine 泄漏常是内存泄漏的“影子”
大量 goroutine 卡在 channel recv、select 或 mutex 上，会间接导致内存无法释放——比如它们持有了大对象的引用，或阻塞了清理逻辑。
- 访问
/debug/pprof/goroutine?debug=2，文本格式可直接看到所有 goroutine 的完整调用栈 - 重点搜
chan receive、select、semacquire、runtime.gopark这类关键词 - 如果某个函数出现在成千上万个 goroutine 栈顶（比如
client.go:72），基本就是泄漏源头，不用犹豫
pprof 分析时必须带原始二进制文件
离线分析时，go tool pprof 如果找不到编译时的可执行文件，函数名会变成 goph.newunknown 或 runtime.mcall 这种无法定位的符号，根本没法修。
立即学习“go语言免费学习笔记（深入）”；
- 部署时务必保留构建产物：把服务二进制文件和对应 pprof 快照一起存档
- 命令要写全：
go tool pprof ./myapp http://host:6060/debug/pprof/heap?gc=1，不能省略./myapp - 用 Docker 的话，在构建阶段 COPY 二进制到宿主机，或挂载 volume 保存 profile 文件
生产环境开启 pprof 的三个硬约束
线上开 pprof 不是“加一行 import 就完事”，没控制好反而引发新问题。
- 端口必须绑定到
127.0.0.1:6060或内网地址，绝不能监听:6060暴露到公网 - HTTP mux 不能复用主服务路由（比如 Gin 的
r），否则中间件可能拦截或日志泄露敏感路径 - 建议加一层反向代理鉴权，或者用
http.HandlerFunc手动包装，检查X-Forwarded-For或 token
真正难的不是跑出火焰图，而是看懂那张图里谁在 hold reference——比如一个闭包捕获了整个 struct，而 struct 里有个大 slice；或者 sync.Pool 误用了指针类型，导致对象永远不被回收。这些细节，pprof 只字不提，得你一帧一帧翻栈、一行一行查引用。
