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 前后变化、或定位某段代码是否触发了额外堆增长），就得手动打点。
注意点：
立即学习“go语言免费学习笔记（深入）”；
- 必须在
b.ResetTimer()前后分别调用runtime.ReadMemStats，否则计时和内存统计会互相干扰 - 关注
MemStats.Alloc（当前已分配且未释放的字节数）和MemStats.TotalAlloc（历史总分配字节数），前者反映“驻留内存”，后者反映“累计开销” - 别直接比较
Alloc绝对值——GC 可能在任意时刻运行，应多次运行取稳定值，或用runtime.GC()强制触发后读取
避免逃逸分析干扰导致的假阳性
很多看似“零分配”的函数，在基准测试中却报告非零 allocs/op，大概率是变量逃逸到了堆上。编译器逃逸分析（go build -gcflags="-m" ）才是真相来源。
常见诱因：
- 返回局部切片/结构体指针（如
return &T{}） - 将局部变量传给
interface{}参数（如fmt.Sprintf、append到全局 slice） - 闭包捕获了大对象或其字段
- 使用
reflect或unsafe相关操作，编译器保守起见直接标为逃逸
验证方式：运行 go tool compile -S -l -m=2 your_file.go，搜 escapes to heap。
对比不同实现时，确保测试逻辑等价且无隐藏副作用
写两个版本做内存对比（比如 map[string]int vs sync.Map），最容易出错的是没清空状态或复用对象。
典型陷阱：
- 在
b.ResetTimer()之前初始化 map 或 slice，导致首次迭代的扩容成本被计入后续所有轮次 - 复用同一个
bytes.Buffer而没调用.Reset()，后续迭代实际是追加而非重写，分配量虚低 - 测试中用了全局变量或包级变量，多次
b.N迭代之间状态污染（尤其涉及缓存、计数器） - 没控制输入规模：比如固定 key 数量但 value 长度随机波动，会导致字节统计抖动极大
真正干净的对比，应该让每次迭代都从相同初始状态开始，且只测目标操作本身——哪怕多写几行 make 和 reset，也比省事埋坑强。
内存基准测试里最麻烦的从来不是跑命令，而是确认你测的真是你想测的那一小段逻辑，而不是它周边的噪音。
