启动 pprof 内存分析需暴露 /debug/pprof 路由：导入 _ "net/http/pprof" 并调用 http.ListenAndServe("localhost:6060", nil)；若用 Gin 则用 gin-contrib/pprof；线上须改 localhost 为可访问 IP；查真实内存用 ?gc=1 触发 GC 后采集 heap，查分配频次用 allocs；flat 高表明函数自身持有内存，是泄漏主因；确认泄漏需多次采集比对 inuse_space/objects 是否持续增长。
怎么启动 pprof 内存分析接口？
必须让程序暴露 /debug/pprof 路由，否则所有后续命令都会 404。最简方式是导入 _ "net/http/pprof"，它会自动注册 handler；但注意：**只导入不启动 HTTP 服务等于没开**。
- 要显式调用
http.ListenAndServe("localhost:6060", nil)，端口可自定义，但别被防火墙或线上环境限制（比如云主机默认只开放 80/443） - 如果用
gin等框架，别直接 importnet/http/pprof，改用对应中间件，例如github.com/gin-contrib/pprof的pprof.Register(r) - 本地测试时用
localhost，线上排查必须把localhost换成实际 IP 或域名，且确保该地址能从你运行go tool pprof的机器访问到
抓 heap profile 为什么总看不到真实内存占用？
pprof 默认采样堆分配（allocs），不是当前存活对象（inuse）。你看到“内存不大”，可能只是采样率太低，或 GC 刚跑完——这不是数据不准，是指标含义不同。
- 查“此刻正在用的内存”，用
go tool pprof http://localhost:6060/debug/pprof/heap?gc=1：加?gc=1会先触发一次 GC，再采集，更接近真实 inuse - 查“最近分配过多少”，用
/debug/pprof/allocs，适合定位高频小对象（如循环里反复make([]byte, 1024)） - pprof 是采样机制，默认 1/1000 分配才记录，所以极小对象或短命对象容易漏掉；如需更高精度，启动前设环境变量
GODEBUG=gctrace=1观察 GC 日志中内存变化趋势
top 命令里 flat 和 cum 到底看哪个？
flat 表示函数自己分配并持有的内存，cum 是它及所有下游调用分配的总和。**内存泄漏几乎总是 flat 高的函数惹的祸**，因为它意味着“这个函数创建了大对象，还一直拿着不放”。
- 比如
top显示main.loadConfig的flat占 95%，cum也是 95%，说明问题就出在它内部——可能是读了整个大文件到全局map里没清理 - 如果
flat很低但cum很高（比如runtime.mallocgc），说明是下游某函数在疯狂分配，这时要用list 函数名看具体哪行代码在 new / make - 别迷信 top 10 排名，有时第 11 名的函数虽然占比小，但它是唯一长期持有缓存的入口，得结合调用栈判断
怎么确认是不是真泄漏，而不是暂时没 GC？
真正的泄漏表现为：多次采集 heap profile，同一类对象数量或内存持续增长，且 GC 后也不回落。单次截图毫无意义。
立即学习“go语言免费学习笔记（深入）”；
- 至少采集 3 次：刚启动时、运行 5 分钟后、再运行 5 分钟后；每次用
go tool pprof -http=:8080 http://x.x.x.x:6060/debug/pprof/heap?gc=1直接打开可视化界面比对 - 重点关注
inuse_space（当前占用字节数）和inuse_objects（当前对象个数）两个视图，看曲线是否单调上升 - 常见假阳性：全局
sync.Pool、bigcache这类缓存组件，它们会主动 hold 住内存，但属于合理设计；要对比文档说明的容量上限和实际值
最容易被忽略的是 goroutine 持有引用——一个常驻 goroutine 里有个闭包捕获了大结构体，或者 channel 未关闭导致 sender/receiver 无法退出，这种泄漏不会体现在 heap top 里，得配合 /debug/pprof/goroutine?debug=2 看完整栈。
