确认内存泄漏需监控inuse_space持续上涨，而非allocs；用pprof比对两次heap快照，结合goroutine分析阻塞态及未释放资源，离线分析须保留原始二进制文件，并严格管控pprof暴露范围。
怎么确认是内存泄漏而不是临时分配高
内存泄漏的本质是对象持续存活、无法被 GC 回收，所以必须盯 inuse_space，不是 allocs。后者高只说明分配频繁，GC 后就没了；前者持续上涨才可疑。
操作步骤：
- 访问
/debug/pprof/heap?inuse_space获取当前存活堆大小，记下数值（如 120MB） - 等 2–5 分钟再抓一次，仍为 120MB → 基本排除泄漏；涨到 180MB → 需继续查
- 绝对不要用
go tool pprof http://localhost:6060/debug/pprof/heap直接看，默认只抓瞬时快照，看不出趋势 - 正确比对方式：
go tool pprof -base heap0.pb.gz heap1.pb.gz，它会标出新增的存活对象来源
为什么 heap profile 看不出泄漏，但 goroutine 数暴涨
goroutine 本身开销小（初始栈 2KB），但它只要活着，就可能“钉住”大对象——比如闭包捕获了含 []byte 的 struct，或 channel 接收者一直挂着 map 引用。这时 heap 里看不到泄漏源头，因为 GC 不敢动。
立刻做两件事：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 访问
/debug/pprof/goroutine?debug=2：只有?debug=2才输出完整调用栈，?debug=1只给统计摘要 - 重点搜
chan receive、select、time.Sleep、http.Transport等阻塞态，尤其是重复出现的业务文件行号（如client.go:72） - 若发现某函数启动了上千个 goroutine 且状态全是
IO wait或semacquire，大概率是未关闭的 channel 或无超时的 HTTP client
pprof 分析时必须带原始二进制文件
离线分析时，go tool pprof 如果找不到编译时的可执行文件，函数名会变成 goph.newunknown 或 runtime.mcall 这种无法定位的符号，根本没法修。
部署时务必保留构建产物：
- 把服务二进制文件和对应 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 里有个大 []byte，你得顺着调用栈一层层点进去，直到看到业务代码里的变量名。
