Go testing.B.Loop 怎样编写稳定基准循环

如果你写过 Go 基准，可能见过这样的误差：准备输入的时间被算进结果，或者函数返回值没有被使用，编译器让循环体变得和预想不一样。Go 1.24 起，testing.B.Loop 提供了更稳定的基准循环写法。

官方地址：https://pkg.go.dev/testing

本文从一个很小的字符串统计项目开始，只测量 strings.Count，把 setup、循环体和 cleanup 分开。结论先说：新基准优先写成 for b.Loop() { ... }，不要在同一个基准里同时维护 b.N 循环。

先看 b.Loop 解决的计时边界

旧式基准通常写成 for i := 0; i 。当循环前要构造较大的输入时，作者需要自己判断是否调用 b.ResetTimer；循环后还有清理工作时，又要记得停止计时。漏掉任意一个边界，测到的就不只是目标函数。

b.Loop 把这件事收进循环协议：第一次调用时开始真正的基准计时，返回 false 后停止计时。因此循环前准备输入，循环后做清理，都不会自动混入测量区。它还让循环体里的函数参数、返回值和赋值变量保持存活，降低结果被编译器完全优化掉的风险。

从零写一个稳定的字符串基准

创建一个以 _test.go 结尾的文件。示例故意把输入准备放到循环外，把每次要测的动作放进唯一的 b.Loop 循环中。

package counter

import (
    "strings"
    "testing"
)

func BenchmarkCount(b *testing.B) {
    // 只准备一次输入，避免把构造样本的成本算进每次统计。
    input := strings.Repeat("INFO request completed\n", 128)
    const target = "completed"

    for b.Loop() {
        // 循环体只保留本次要测量的字符串查找。
        count := strings.Count(input, target)
        // 使用结果避免示例看起来像无效计算；b.Loop 也会帮助保持结果存活。
        if count == 0 {
            b.Fatal("未找到目标文本")
        }
    }
}

这里的关键不是 strings.Count 有多快，而是边界清楚：strings.Repeat 只执行一次，Count 进入计时循环，错误处理也在循环体内保持可见。真实项目中，如果输入是固定 fixture，可以在循环外读取；如果每次迭代都必须重新生成输入，则要显式管理那段代码是否应该计入目标指标。

在项目根目录运行下面的命令即可查看基准结果：

# 只运行基准函数，并把分配信息一起打印出来
go test -run '^$' -bench '^BenchmarkCount$' -benchmem

循环体里哪些写法会改变结果

for b.Loop() 需要保持这个精确形式。不要把它改成先保存布尔值再放进循环条件，也不要在同一函数里再写一个 for range b.N。官方实现会识别这个特定循环形状，并据此管理计时和循环体的保活。

循环结束后，b.N 仍然包含本轮实际执行的迭代次数。如果你要用迭代数计算自定义指标，可以在循环之后读取它；不要依赖循环中的当前次数来改变每一轮的工作，否则基准会从“重复同一个目标动作”变成另一种算法。

从 b.N 迁移时记住三个边界

第一，先把循环条件替换为 for b.Loop()，再检查循环体是否每轮做同一件事。第二，删掉只为覆盖 setup 的 ResetTimer 和只为覆盖 cleanup 的 StopTimer；它们不再是外层边界的必需品。第三，如果每次迭代内部有一段不应计入指标的准备，仍然要在循环体中手动使用 b.StopTimer 和 b.StartTimer。

可以用下面的表快速判断：

验收时只需要确认三件事：基准函数里只有一个 b.Loop 循环；准备输入的代码位于第一次调用之前；循环结束后的清理和自定义统计没有被误放进测量区。这样写出的结果才是在回答“目标代码每轮花费多少”，而不是回答“整个基准函数跑一遍花费多少”。

常见问题

b.Loop 适用于哪个 Go 版本？

它从 Go 1.24 开始提供。如果项目必须兼容更早版本，应继续使用 b.N 写法，并明确处理计时器；不要在旧工具链中直接引用 b.Loop。

为什么不能同时写 b.Loop 和 b.N？

两者都是一套完整的基准迭代协议。混用会让循环次数、计时边界和代码意图难以判断；一个基准函数选择一种写法即可。

总结

testing.B.Loop 的价值是把基准循环的协议写得更直接：循环前准备，循环中只放目标动作，循环后清理。它从 Go 1.24 起成为新基准的优先选择。迁移时重点检查唯一循环、setup/cleanup 边界，以及每轮是否真的在做同一件事。