需调用 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 虚高。
更隐蔽的问题是闭包捕获变量导致隐式分配。比如：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func BenchmarkBad(b *testing.B) {
data := make([]byte, 1024)
b.ReportAllocs()
b.ResetTimer()
for i := 0; i < b.N; i++ {
// 这个匿名函数会逃逸，data 被抬升到堆上
f := func() { _ = len(data) }
f()
}
}
应改为直接使用，或确保闭包不捕获大对象。
- 所有预分配资源（如
sync.Pool、缓存 map、预置 slice）应在b.ResetTimer()前完成 - 循环内尽量复用对象，用
Reset()、Truncate(0)、buf = buf[:0]清空而非重建 - 注意
fmt.Sprintf总是分配新字符串，高频场景换成bytes.Buffer或strconv系列
区分栈分配和堆分配：逃逸分析比基准测试更早发现问题
go test -bench=. 测的是最终运行时行为，但很多分配问题其实在编译期就能发现。用 go tool compile -S -l -m main.go（或 -gcflags="-m -m"）看逃逸分析输出，关键线索是 ... escapes to heap。
典型逃逸场景包括：返回局部变量地址、传入接口类型参数（如 fmt.Println(x) 中的 x 若是结构体且方法集含指针接收者）、闭包捕获、slice 超出初始栈容量等。
- 小结构体（
）不一定逃逸，但一旦取地址或作为接口值传递，大概率逃逸 -
for range中的value变量在 Go 1.21+ 默认不逃逸，但若把它取地址传给函数，依然会逃逸 - 用
unsafe.Sizeof检查结构体大小，辅助判断是否可能被栈分配
用 runtime.ReadMemStats 抓瞬时分配峰值（慎用）
当需要观察单次操作的瞬时堆增长（比如某个函数触发了意外的 GC 或大量临时对象），可以手动调用 runtime.ReadMemStats 做前后对比。但这会引入 stop-the-world 开销，严重污染基准结果，仅适合诊断性探查，绝不能留在正式 Benchmark 函数中。
正确做法是单独写一个非基准的测试函数，用 log.Printf 输出差值，或者用 pprof 抓 profile。
- 不要在
b.N循环内调用ReadMemStats—— 它本身就会分配内存并暂停调度 - 若真要量化某段逻辑的净分配，用
testing.AllocsPerRun配合testing.B.Run分层测试更可靠 - pprof 的
allocsprofile 记录的是所有分配事件，包括 tiny alloc，比基准测试的汇总数据更细粒度
allocs/op 从 0 变成 3——这往往卡在逃逸分析边界、接口动态调度、或编译器对闭包的处理上。 
