内存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() 后再抓。

https://www.php.cn/faq/2006359.html