pprof 默认不采集堆分配速率，需启用 runtime.memprofilerate 或抓取 allocs profile；allocs 记录累计分配量，结合 -seconds 可计算速率；heap profile 显示驻留内存，二者不可混用。
pprof 默认抓不到堆分配速率，得手动开 flag
Go 的 runtime/pprof 默认只采集堆内存的当前快照（heap），不记录分配事件流。想看“每秒分配多少字节”，必须启用 runtime.MemProfileRate 并设为非零值，或者更直接——用 go tool pprof 抓取 allocs 类型的 profile。
常见错误是直接访问 /debug/pprof/heap，结果看到的全是 live objects，完全看不出分配热点或速率趋势。
-
MemProfileRate = 0（默认）→ 不采样分配事件，allocsprofile 为空 -
MemProfileRate = 1→ 每次分配都记录，性能损耗极大，仅限本地调试 - 生产环境建议设为
512 * 1024（即 512KB 采样一次），平衡精度与开销 - 启动时加
-gcflags="-m"不能替代 pprof，它只输出编译期逃逸分析，不反映运行时分配行为
用 allocs profile 查分配速率，不是 heap profile
allocs profile 记录的是自程序启动以来所有堆分配的调用栈（含已释放对象），所以它天然适合算“累计分配量”和“分配频次”。结合 -seconds 参数，就能推导出速率。
实操步骤：
- 确保服务暴露
/debug/pprof/（导入_ "net/http/pprof"） - 用
curl -s http://localhost:6060/debug/pprof/allocs?seconds=30 > allocs.pprof抓 30 秒样本 - 执行
go tool pprof -http=":8080" allocs.pprof，打开 Web 界面后选 “Top” 或 “Flame Graph” - 关键指标看
flat列的bytes值，除以时间就是平均分配速率（如 15MB / 30s = 500KB/s）
注意：heap profile 的 inuse_space 是当前驻留内存，和 allocs 的 alloc_space 完全不同，混用会导致误判。
用 runtime.ReadMemStats 验证分配总量是否突增
pprof 是采样机制，有延迟且不可实时。如果要写监控告警或做自动化检测，得搭配 runtime.ReadMemStats 拿到精确的累计分配字节数（Mallocs 和 TotalAlloc 字段）。
示例逻辑：
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("Total allocated: %v MB\n", m.TotalAlloc/1024/1024)
- 每秒调用一次
ReadMemStats，计算TotalAlloc差值，就是该秒实际分配量 -
Mallocs是分配次数，可用于识别高频小对象（如频繁 new struct{}） - 该方式无采样偏差，但会增加少量 runtime 调用开销，建议间隔 ≥100ms
- 别依赖
HeapAlloc算分配速率——它是当前已分配未释放的量，不是增量
容易被忽略的 GC 干扰和 false positive
分配速率高 ≠ 内存泄漏。GC 会重用内存块，导致 allocs profile 显示高分配，但 heap profile 却很平稳。这时候得交叉验证。
- 如果
allocs中某函数分配量大，但heap里没它 → 大概率是短生命周期对象，GC 及时回收了 - 如果
allocs和heap都在增长 → 才值得怀疑泄漏或缓存未清理 - 开启
GODEBUG=gctrace=1观察 GC 频次：若分配速率稳定但 GC 次数暴增，说明对象存活期变短、GC 压力上升 - 注意字符串拼接、
fmt.Sprintf、bytes.Buffer扩容等隐式分配，它们常出现在 profile 底层但不易察觉
真正难的是区分“合理高频分配”和“可优化分配”，比如日志打点中反复构造 map[string]interface{}，这类问题不会报错，但压测时会突然拖垮吞吐。
