Go内存基准测试需用testing.B配合-benchmem标志，调用b.ReportAllocs()开启统计，关注B/op和allocs/op；需用runtime.ReadMemStats获取细粒度数据，注意GC干扰与逃逸分析，确保测试逻辑纯净。
用 testing.B 测内存分配次数和字节数
Go 的基准测试框架原生支持内存统计，关键不是看耗时，而是启用 -benchmem 标志。不加这个，b.ReportAllocs() 不生效，b.N 循环里的分配数据全为 0。
实操要点：
- 函数签名必须是
func BenchmarkXxx(b *testing.B)，且放在_test.go文件中 - 在函数开头调用
b.ReportAllocs()，显式开启分配统计 - 运行命令必须带
-benchmem：例如go test -bench=^BenchmarkMapCreate$ -benchmem - 输出中的
B/op表示每次操作平均分配字节数，allocs/op是每次操作的堆分配次数
runtime.ReadMemStats 捕获更细粒度的内存快照
当 testing.B 提供的汇总数据不够用（比如想观察 GC 前后变化、或定位某段代码是否触发了额外堆增长），就得手动打点。
注意点：
- 必须在
b.ResetTimer()前后分别调用runtime.ReadMemStats，否则计时和内存统计会互相干扰 - 关注
MemStats.Alloc（当前已分配且未释放的字节数）和MemStats.TotalAlloc（历史总分配字节数），前者反映“驻留内存”，后者反映“累计开销” - 别直接比较
Alloc绝对值——GC 可能在任意时刻运行，应多次运行取稳定值，或用runtime.GC()强制触发后读取
避免逃逸分析干扰导致的假阳性
很多看似“零分配”的函数，在基准测试中却报告非零 allocs/op，大概率是变量逃逸到了堆上。编译器逃逸分析（go build -gcflags="-m" ）才是真相来源。
常见诱因：
