最稳的线上 heap profile 采样方式是启用 net/http/pprof 后访问 /debug/pprof/heap（不带 ?gc=1），需导入 _ "net/http/pprof" 并在 http.listenandserve 前注册，采样应选业务低峰期或增长初现时，避免 ?gc=1 强制 gc 掩盖真实泄漏。
怎么触发一次靠谱的 heap profile 采样
线上服务内存疑似上涨，但 pprof.WriteHeapProfile 又不能随便在生产环境里“打点”——最稳的方式是启用 net/http/pprof，然后访问 /debug/pprof/heap（不带 ?gc=1）。
- 必须导入
_ "net/http/pprof"，且在http.ListenAndServe前完成注册（Go 会自动注册路由） - 采样时机很重要：不要等 OOM 再抓，建议在业务低峰期、或增长趋势刚出现时立刻抓一次，再隔 2–5 分钟抓第二次，用于对比
-
?gc=1是个常见误区——它强制 GC 后采样，会把本该存活的对象“刷掉”，掩盖真实泄漏；默认路径才反映「GC 后仍驻留」的内存 - 如果程序没开 HTTP 服务，也可以临时加个 goroutine：
go http.ListenAndServe("127.0.0.1:6060", nil)，只要端口不冲突，不影响主逻辑
用 go tool pprof 看懂 .heap 文件的关键视图
拿到 heap.out 后，go tool pprof heap.out 进入交互界面，默认展示的是 inuse_space（当前存活对象占的内存），但这只是冰山一角。
- 想查高频小对象分配（比如反复 new struct{}、字符串拼接），必须切到
Allocation space：右上角 View → Allocation space，否则top列出来的函数可能完全“不相关” -
inuse_objects和inuse_space要一起看：如果对象数持续涨但单个对象很小，大概率是 map/sync.Map 无节制写入、key 不重复但 value 持续变大 -
list 函数名能定位到具体哪行代码在分配，但要注意：逃逸分析导致的堆分配（如返回局部变量地址）也会出现在这里，不是所有堆分配都等于泄漏 - 用
web命令生成火焰图前，确保系统已装graphviz；若失败，先brew install graphviz（macOS）或apt install graphviz（Linux）
runtime.MemProfileRate 设置不当的典型后果
runtime.MemProfileRate 控制采样频率，默认是 512KB（即每分配 512KB 记一次调用栈），设太高或太低都会误导判断。
- 设成 0：完全关闭采样，
WriteHeapProfile仍能写，但内容为空（别信文档说“全量采集”，Go 早就不支持了） - 设成 1：每字节都采样——内存和 CPU 开销飙升，线上绝对禁用，本地调试也慎用
- 设成 1024 或 2048：适合高吞吐服务，降低开销，但可能漏掉短生命周期的小对象分配模式
- 真正要调的不是这个值，而是采样时机：与其调低
MemProfileRate，不如多抓几个时间点的快照做差分分析
为什么 inuse_space 稳定，程序还在 OOM
这是最让人困惑的场景：pprof 显示内存稳定，但 RSS 持续上涨，最终被系统 kill。根本原因在于 Go 的内存管理机制和 pprof 的观测边界。
-
inuse_space只统计 Go runtime 管理的堆内存，不包含 mmap 分配的 arena、未归还给系统的页、CGO 分配的内存（如 C malloc） - GC 之后内存没立即还给 OS，尤其当
GODEBUG=madvdontneed=1未启用时，RSS 会虚高；可用cat /proc/PID/status | grep VmRSS对比 RSS 和 pprof 数据 - sync.Pool 使用不当（Put 了不该 Put 的对象）、cgo 调用泄漏、或第三方库用
unsafe手动管理内存，都不会出现在 heap profile 里 - 此时应补充检查：
/debug/pprof/mutex（锁竞争拖慢 GC）、/debug/pprof/goroutine?debug=2（goroutine 泄漏间接拖垮内存）、以及GODEBUG=gctrace=1日志看 GC 频次和停顿是否异常
内存分析最难的不是工具怎么用，而是区分「Go 堆里的问题」和「操作系统视角的问题」；pprof 是显微镜，不是万能透视仪。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
