Go testing.B.Loop 怎么写基准：循环边界、计时窗口与基准结果核对

写基准测试时，最容易被忽略的不是循环语法，而是“哪些代码被计时了”。Go 1.24 加入 testing.B.Loop 后，可以把测试对象直接放进 for b.Loop()，初始化和清理自然落在计时区间外，结果也更不容易被编译器优化掉。

先搭一个能复查的基准实验

下面用一个字符串标签查找实验，比较 strings.Contains 的两种输入路径。示例故意不追求复杂算法，重点是让计时边界和结果核对都能看见。

package label

import (
    "strings"
    "testing"
)

var labelResult bool

func BenchmarkContainsLoop(b *testing.B) {
    text := strings.Repeat("service=api;", 64) + "trace=enabled;"
    needle := "trace=enabled"

    for b.Loop() {
        labelResult = strings.Contains(text, needle)
    }
}

这里把结果写入包级变量，是为了让示例的返回值有去处。真实项目也可以把结果交给后续校验，但不要为了“让基准跑起来”随手丢掉核心计算。

循环前的初始化为什么不计时

B.Loop 的第一个 true 返回之前，基准仍处于准备阶段。把大字符串、正则表达式或测试数据放在循环前，通常比在循环里反复构造更符合“只测目标操作”的意图。

但这不等于所有准备工作都可以无条件移出去。如果生产代码每次请求都会创建解析器，那么创建成本就是被测行为的一部分；此时应该保留在循环内，并在标题或注释中写清测试口径。

从 b.N 迁移到 B.Loop 要核对哪三件事

旧基准常见写法如下：

func BenchmarkContainsN(b *testing.B) {
    text := strings.Repeat("service=api;", 64) + "trace=enabled;"
    needle := "trace=enabled"
    b.ResetTimer()

    for i := 0; i 

改成 B.Loop 时，不要保留 b.ResetTimer 再套一层 b.N。逐项检查下面的边界：

运行结果时不要只盯着一个 ns/op

把文件保存为 label_test.go 后运行：

go test -run '^$' -bench '^BenchmarkContains' -benchmem -count=5

输出中的 ns/op 是每次循环的平均耗时，B/op 和 allocs/op 则帮助判断是否引入了分配。单次结果容易受 CPU 频率、后台进程和缓存状态影响，至少用多次运行观察范围，不要把 1% 的变化直接当成优化结论。

如果要比较两个版本，可以分别保存基准结果，再使用 benchstat old.txt new.txt。只有当差异方向稳定、分配指标也符合预期时，才值得继续检查代码审查和真实流量。

常见问题

能不能在 Loop 里读取当前迭代次数？

不要把业务逻辑建立在“第几轮”上。B.Loop 的目标是让基准控制循环次数，测试体应当每轮做同一类工作。

初始化很慢，要不要手动 ResetTimer？

通常不需要。只要初始化位于第一次 b.Loop() 之前，计时就不会包含它。若初始化本身就是测量目标，再把它明确放入循环，而不是用计时器掩盖口径。

旧版本 Go 能直接编译 B.Loop 吗？

B.Loop 从 Go 1.24 起提供。需要兼容更旧工具链时，应保留 b.N 版本或通过构建约束拆分实现，先在 CI 中确认 go.mod 和实际编译器版本。

收尾检查清单

提交基准代码前，顺着这四个问题走一遍：循环内是不是只有目标操作？输入和清理是否符合测量口径？返回值有没有被有效保留？重复运行后 ns/op、B/op 和 allocs/op 是否支持你的判断？这几项都能回答清楚，基准结果才有比较价值。