内存Profiling能直接暴露的三类典型问题是：①goroutine持有大量临时切片或map且未及时清理；②频繁生成短生命周期大对象导致高频GC和堆碎片；③闭包捕获大结构体指针致底层数据滞留堆中。
内存Profiling能直接暴露的三类典型问题
Go 的 pprof 内存分析（allocs 和 heap）不是用来“看内存用了多少”，而是定位「谁在什么时机申请了什么、为什么没被回收」。它最常帮我们揪出以下三类问题：
-
goroutine持有大量临时切片或 map，但生命周期远超预期（比如注册到全局 map 后忘记清理） - 频繁调用
make([]byte, n)或strings.Repeat生成短生命周期大对象，触发高频 GC 和堆碎片 - 闭包捕获了大结构体指针，导致本该被回收的底层数据因引用链残留而滞留堆中
allocs vs heap：该看哪个 profile？
二者数据来源不同，解决的问题也不同：
-
allocs记录的是「所有 malloc 调用」，包括已被 GC 回收的对象 —— 适合查「哪里在疯狂分配」，比如某个 HTTP handler 每次请求都json.Marshal一个 2MB 结构体 -
heap只抓取「当前存活对象」的堆快照 —— 适合查「内存泄漏」，比如某个后台goroutine不断往var cache = make(map[string]*HeavyStruct)里塞数据却从不删除
实际排查时，先看 allocs 找高分配热点，再切到 heap 看这些热点是否积累了大量存活对象。
用 go tool pprof 分析时最容易忽略的两个细节
很多同学跑完 go tool pprof http://localhost:6060/debug/pprof/heap 就直接 top，结果看到的全是 runtime 函数，根本看不出业务代码在哪。关键在于：
立即学习“go语言免费学习笔记（深入）”；
- 必须加
-http=启动 Web 界面，用图形化视图点开「focus」过滤你自己的包名（比如myapp/handler），否则默认展示的是整个调用树顶层 - 默认采样是基于「对象数量」而非「字节大小」；想看谁占内存最多，得在 Web 界面右上角把
Sample value type切成inuse_space（对heap）或alloc_space（对allocs）
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap
如何验证某个疑似泄漏点是否真在增长？
单次 profile 快照只能反映瞬时状态。要确认泄漏，得做差分对比：
- 启动服务后立刻抓一次：
wget -O heap1.pb.gz "http://localhost:6060/debug/pprof/heap?debug=1" - 模拟稳定负载运行 5 分钟（比如用
hey -z 5m http://localhost/api） - 再抓一次：
wget -O heap2.pb.gz "http://localhost:6060/debug/pprof/heap?debug=1" - 用
go tool pprof -base heap1.pb.gz heap2.pb.gz，它会高亮显示净增长的对象分配路径
注意：heap profile 默认只在 GC 后采样，如果程序长期不触发 GC（比如分配少、对象小），可能抓不到真实堆积 —— 这时可手动调用 runtime.GC() 后再抓。
