runtime.memprofile 采不到持续增长的堆内存，因其默认仅在 gc 后采样且只记录存活对象；长期存活对象（如未清理全局 map、goroutine 泄漏、缓存未驱逐）导致的内存增长不会体现于 profile 中。
runtime.MemProfile 为什么采不到持续增长的堆内存？
它默认只在 GC 后采样，且仅记录当时存活对象——如果内存增长来自长期存活对象（比如全局 map 未清理、goroutine 泄漏、缓存未驱逐），runtime.MemProfile 生成的 profile 文件里确实可能“看起来没涨”。这不是 bug，是设计使然：它反映的是“当前堆快照”，不是“增量变化”。
实操建议：
- 必须配合
runtime.GC()主动触发一次 GC 后再调用runtime.WriteHeapProfile（MemProfile已被弃用，Go 1.17+ 应用runtime/pprof.WriteHeapProfile） - 避免只采一次：连续多次采样（如每 30 秒一次，持续 5 分钟），对比
inuse_objects和inuse_space的趋势 - 优先用
pprof.Lookup("heap").WriteTo，而非手动遍历runtime.MemProfile返回的[]runtime.MemProfileRecord，后者易漏掉 symbol 信息
用 pprof 分析 heap profile 时，哪些字段真正关键？
打开 go tool pprof 后，别急着看 top；先确认采样模式是否为 inuse_space（默认）还是 alloc_space。前者对应当前存活内存，后者对应累计分配量——定位“持续增长”必须用 inuse_space。
重点关注：
-
flat：该函数直接分配的内存（不含调用栈下游），适合找“谁 new 了大对象” -
cum：包含调用链路的累积值，用于定位“哪条路径整体吃内存” -
show --text=".*Handler.*"这类正则过滤，比盲目 top 更快锁定业务代码段 - 用
web或svg查看调用图时，注意红色节点（高 inuse）是否指向你自己的 handler、cache 初始化或 goroutine 启动点
常见误判：把 runtime.goroutine 占用当成堆内存泄漏
goroutine 泄漏会拖慢调度、抬高 runtime.mstats.GCCPUFraction，但不直接增加 heap profile 中的 inuse_space。它的栈内存（stack）算在 runtime.mstats.StackInuse，不在 heap profile 范围内。
验证方式：
- 运行
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看活跃 goroutine 堆栈，搜select { case 或 <code>time.Sleep长等待 - 对比
runtime.ReadMemStats中的StackInuse和HeapInuse增长斜率：若前者涨得更快，大概率是 goroutine 泄漏而非堆泄漏 - heap profile 里出现大量
runtime.newobject或runtime.malg调用，往往暗示底层在频繁创建 goroutine 或 sync.Pool 对象，需回溯上层逻辑
生产环境安全采样的三个硬约束
别在高峰期用 pprof.WriteHeapProfile 写全量 profile——它会 STW 几毫秒，且生成百 MB 文件。实际可用的折中方案：
- 用
net/http/pprof的/debug/pprof/heap?gc=1（强制 GC 后采样），并加?seconds=30参数限制阻塞时间 - 设置采样速率：通过
runtime.SetMutexProfileFraction(0)和runtime.SetBlockProfileRate(0)关闭无关 profile，减少开销 - 写入临时文件时指定路径为
/dev/shm/（内存盘），避免磁盘 IO 拖慢进程；采完立即gzip并curl -F "file=@heap.pb.gz" upload.example.com异步上传
真正难的不是拿到 profile，而是把 inuse_space 的增长和某次 HTTP 请求、某个定时任务、某条 Kafka 消息消费逻辑对应起来——这需要你在 profile 采样时刻同步记录 trace ID 和业务上下文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
