需调用 b.reportallocs() 并加 -benchmem 标志才能统计 allocs/op 和 b/op；allocs/op 反映 gc 压力，应优先优化；reportallocs() 需在 resettimer 前后调用，不可在 stop/starttimer 间；避免循环外初始化和闭包隐式分配。
用 testing.B 的 AllocsPerOp() 和 ReportAllocs() 看真实分配次数
Go 的基准测试默认不统计内存分配，必须显式开启。直接运行 go test -bench=. 不会输出 alloc 数据，得加 -benchmem 标志。在测试函数里调用 b.ReportAllocs() 才会让结果包含 allocs/op 和 B/op 两列——前者是每次操作的堆分配次数，后者是平均每次操作分配的字节数。
常见误区是只看 B/op 忽略 allocs/op：一次分配 1KB 和一百次分配 10B 对 GC 压力完全不同。实际优化时，优先压低 allocs/op。
-
b.ReportAllocs()必须在b.ResetTimer()之前或之后调用，但不能在b.StopTimer()和b.StartTimer()之间（否则统计失效） - 如果函数内有逃逸到堆的局部变量（比如返回局部切片指针），
allocs/op会立刻跳涨，这是编译器逃逸分析的结果，不是代码写错了 - 想验证是否真的没分配，可配合
go build -gcflags="-m -m"看逃逸分析日志
避免测试代码自身干扰：别在 b.N 循环里初始化依赖对象
基准测试里反复执行的逻辑必须严格限定在 b.N 循环体内，否则初始化开销会被计入结果。例如，把 var buf bytes.Buffer 写在循环外再反复 buf.Reset()，比每次循环都 new(bytes.Buffer) 更准——后者会让 allocs/op 虚高。
更隐蔽的问题是闭包捕获变量导致隐式分配。比如：
