pprof 默认不采集内存分配数据，需手动设置 runtime.memprofilerate（如 512*1024）启用采样；/debug/pprof/heap 默认返回存活内存（inuse_space），查分配行为须加 ?alloc_space 或 ?alloc_objects 参数。
pprof 默认不采集内存分配数据，得手动开启
Go 的 runtime/pprof 默认只记录堆内存的“当前存活对象”（in-use space），也就是 heap_inuse，它不反映短期分配量。想看谁在疯狂 make、new 或构造临时字符串，必须显式启用分配采样——靠的是 runtime.MemProfileRate。
这个变量控制每分配多少字节就记录一次堆分配事件，默认值是 0（即关闭）。设为 1 表示每次分配都记，但开销太大；生产环境常用 runtime.MemProfileRate = 512 * 1024（每 512KB 记一次），平衡精度与性能影响。
实操建议：
- 在程序启动早期（比如
main函数开头）设置：runtime.MemProfileRate = 512 * 1024 - 如果用
net/http/pprof，它会自动读取该设置，无需额外注册 - 注意：该设置只对后续分配生效，启动阶段的初始化分配不会被捕捉
用 go tool pprof 分析 alloc_objects 和 alloc_space
访问 /debug/pprof/heap 默认返回的是“存活堆”，不是分配总量。要查分配行为，必须加 ?alloc_space 或 ?alloc_objects 查询参数：
-
?alloc_space：按累计分配字节数排序，适合定位大对象或高频小对象分配 -
?alloc_objects：按分配次数排序，适合发现循环里反复append、strings.Builder.String()这类模式 - 两者结果差异很大——比如一个函数每秒分配 1000 次 16B 字符串，
alloc_objects会把它顶到第一，alloc_space可能完全看不到它
命令行分析示例：
go tool pprof http://localhost:8080/debug/pprof/heap?alloc_objects
进交互后输入 top，看到的是调用栈的分配次数；用 web 可视化，节点粗细对应分配频次。
区分 heap_inuse 与 heap_alloc 容易误判泄漏
很多人看到 heap_inuse 长期上涨就断定“内存泄漏”，其实更可能是 heap_alloc（已分配但尚未被 GC 回收的总字节数）持续偏高，而 heap_inuse 稳定——这说明对象在频繁创建又很快被回收，属于 GC 压力大，不是泄漏。
关键指标含义：
-
heap_inuse：当前堆中正在使用的字节数（GC 后仍存活的对象） -
heap_alloc：从程序启动至今所有未被 GC 清理掉的分配总和（含待回收对象） -
gc_next：下一次 GC 触发时的堆大小阈值
若 heap_alloc 接近 gc_next 且 GC 频繁，优先检查 alloc_objects，而不是盯着 heap_inuse 找“泄露点”。
HTTP handler 中启停 profile 需避免竞态
有些场景需要动态开关内存 profile（比如只在某个请求路径下采集 30 秒），不能简单地在 handler 里改 MemProfileRate——因为 Go runtime 的分配采样是全局且无锁的，直接修改会导致统计错乱或 panic。
安全做法只有两种：
- 用
runtime.SetMutexProfileFraction类似的思路不适用，MemProfileRate没有配套的原子设置 API - 真正可控的方式是：启动时设好速率，用
/debug/pprof/heap?&debug=1抓快照，再对比两次快照的差值（diff）来聚焦某段时间的分配 - 或者用
pprof.StartCPUProfile+ 自定义内存打点（如包装make调用），但失去 runtime 级别的完整性
最稳的方案其实是固定采样率，配合时间窗口抓取和 diff 分析——复杂度不高，但容易被忽略的是：两次快照必须用相同采样率，否则差值无意义。
