内存泄漏必须盯inuse_space而非allocs；单次快照无意义，需间隔2–5分钟两次采样比对趋势，若inuse_space持续上涨且不回落，结合goroutine栈与原始二进制离线分析，才能准确定位“钉住”对象的持有者。
内存泄漏必须盯 inuse_space，不是 allocs；只抓一次 /debug/pprof/heap 快照毫无意义，趋势对比才是关键。
怎么确认确实是内存泄漏，而不是临时分配高
Go 的 GC 很快，allocs 高只说明代码分配频繁，GC 后就释放了；真正泄漏的表现是 inuse_space 持续上涨。操作上：
- 访问 http://localhost:6060/debug/pprof/heap?inuse_space，记下返回的数值（比如 142MB）
- 等 2–5 分钟再请求一次，如果涨到 210MB 且不回落，才值得深入
- 绝对不要用 go tool pprof http://localhost:6060/debug/pprof/heap 直接看，默认只拉单次快照，看不出增长源头
如何安全启用 pprof 并获取可分析的 heap 快照
线上环境开 pprof 不是加一行 import 就完事，容易暴露敏感信息或干扰主服务：
- 必须绑定内网地址：http.ListenAndServe("127.0.0.1:6060", nil)，绝不能监听 :6060
- 如果用了 Gin/echo 等框架的路由，nil handler 才能触发 net/http/pprof 自动注册；若用了自定义 http.ServeMux，得手动调用 pprof.RegisterHandlers(mux)（Go 1.21+）
- 抓快照时加 ?gc=1 参数强制 GC：curl -o heap1.pb.gz "http://localhost:6060/debug/pprof/heap?gc=1"，避免残留垃圾干扰判断
离线分析 heap 快照时最常踩的坑
pprof 分析结果全是 runtime.mcall 或 goph.newunknown？大概率是没带原始二进制文件：
- 命令必须写全：go tool pprof ./myapp heap1.pb.gz，./myapp 是编译产物路径，不能省
- Docker 部署时，要么构建阶段 COPY 二进制到宿主机，要么挂载 volume 保存 .pb.gz 和对应二进制
- 比对两次快照用 -base：go tool pprof -base heap0.pb.gz heap1.pb.gz，它会标出新增的存活对象及其分配栈
- 默认看的是 inuse_space，但有些泄漏在 alloc_space 更明显，需显式加参数：go tool pprof -sample_index=alloc_space heap1.pb.gz
goroutine 泄漏会伪装成内存泄漏
heap profile 看不出问题，但内存持续涨、goroutine 数暴涨？很可能是 goroutine “钉住”了大对象：
- 访问 http://localhost:6060/debug/pprof/goroutine?debug=2（注意是 ?debug=2，?debug=1 只给统计）
- 在输出里搜 chan receive、select、time.Sleep、http.Transport，尤其重复出现的业务文件行号（如 client.go:72）
- 若某函数启动了数百个状态为 IO wait 的 goroutine，大概率是未关闭的 channel 或 HTTP client 缺少超时设置
真正难的不是跑通命令，而是把 inuse_space 趋势、goroutine 栈、二进制符号三者对齐——缺一不可，否则看到的只是幻影。
