Go testing.B.Loop 怎么写基准测试：循环语义与旧式 b.N 对比

Go 1.24 以后，基准测试可以把传统的 for range b.N 改成 for b.Loop()。这个改动不只是少写一个计数变量：循环第一次进入时会自动开始计时，退出后会停止计时，循环体里的调用结果也会得到更稳妥的保活处理。下面用一个小型字符串解析基准，把新旧写法放在同一个项目里核对。

新基准优先写成 for b.Loop() { ... }；旧代码不要把 b.Loop() 和 b.N 再套在一起，迁移后重点检查 Go 版本、计时边界和循环体是否仍然只包含目标操作。

先做一个能运行的基准小项目

示例任务很简单：把一行带逗号的商品编号拆成字符串切片。目录只需要一个模块和一个测试文件，方便把结果交给 go test -bench 复查。

mkdir benchloop
cd benchloop
go mod init example.com/benchloop

新建 split_test.go，先准备固定输入，再分别写两种基准。

package benchloop

import (
    "strings"
    "testing"
)

var result []string

func splitIDs() []string {
    return strings.Split("sku-101,sku-204,sku-305,sku-406", ",")
}

func BenchmarkSplitLoop(b *testing.B) {
    for b.Loop() {
        result = splitIDs()
    }
}

func BenchmarkSplitN(b *testing.B) {
    for range b.N {
        result = splitIDs()
    }
}

这里用包级变量接收结果，是为了让示例的目标调用不会因为结果未使用而被整体优化掉。真实项目中也可以用局部变量配合断言或黑盒写入，但不要把校验逻辑塞进被计时的主体。

看懂 B.Loop 的计时边界

b.Loop 首次返回 true 时才开始测量循环体。准备输入、创建测试对象等工作放在循环前，退出后的释放和汇总放在循环后，这些内容不会混入每次操作的耗时。

可以把下面的检查当成迁移后的第一条验收标准：如果把 strings.Split 之前的昂贵初始化放进循环，得到的数字就不再只代表拆分操作；如果在循环里调用 b.ResetTimer，通常说明代码还停留在旧式计时思路。

func BenchmarkSplitLoop(b *testing.B) {
    input := "sku-101,sku-204,sku-305,sku-406"
    for b.Loop() {
        result = strings.Split(input, ",")
    }
}

旧式 b.N 和新循环不要混着写

传统基准由测试框架多次调用函数，并逐步调整 b.N。B.Loop 则让一次基准函数调用覆盖完整的测量循环，并负责计时启动和停止。两套机制的生命周期不同，所以不能写成下面这种双重循环：

// 错误示例：一次基准里重复控制迭代次数
for b.Loop() {
    for range b.N {
        result = splitIDs()
    }
}

实际迁移时只保留其中一种。若项目还需要 Go 1.23 或更早版本编译，继续使用 b.N；若模块最低版本已提升到 Go 1.24，则新基准可以直接采用 b.Loop。不要只因为本机装了新版本，就忽略 CI 的工具链。

运行结果时核对这四件事

在 Go 1.24 或更高版本下执行：

go test -run '^$' -bench 'BenchmarkSplit(Loop|N)$' -benchmem -count=5

可见结果通常包含 ns/op，可能还会有 B/op 和 allocs/op。两种写法的绝对数字不必逐次相同，先确认下面几项：

1. 两个基准确实都被发现，名称没有写错。
2. 循环体只包含目标操作，输入准备没有被意外计时。
3. 输出中的分配次数和字节数符合代码预期，没有因为结果变量位置变化而突然增加。
4. 在同一台机器、同一工具链下重复多次，再用稳定的样本比较变化。

如果要比较迁移前后性能，建议把旧写法和新写法放在同一次命令里跑，不要拿不同机器或不同编译器的单次结果下结论。-count=5 只是增加样本，不会替代对环境噪声的判断。

常见误区与兼容处理

把 b.Loop 写成复杂条件可以吗？

不要改写成带额外条件的复合表达式。官方文档强调，循环条件应保持准确的 b.Loop() 形式，这样编译器和测试框架才能按约定处理循环体。

循环体里的返回值一定不会被优化吗？

B.Loop 会对循环体中的调用和赋值提供更可靠的保活语义，但仍然要让基准表达真实任务。把结果写入包级变量只是示例手段，复杂场景应检查最终值或使用专门的黑盒方法。

Go 1.23 项目能直接调用 b.Loop 吗？

不能。该方法从 Go 1.24 提供。兼容旧工具链时保留 b.N 写法，或者通过文件级构建约束维护两份基准代码，并在 CI 中明确验证最低版本。

相关问题：基准迁移还要检查什么

为什么同一段代码的 ns/op 会波动？

CPU 频率、后台任务、缓存状态和样本数量都会带来波动。固定输入并使用相同命令多跑几次，再比较整体趋势。

并行基准也能用 B.Loop 吗？

并行场景应按官方接口使用 RunParallel 和 PB.Next，不要把串行的 B.Loop 再嵌进并行控制器里。

把迁移结论留在代码旁边

这个改动最适合新写的基准和正在清理的旧测试：先确认模块和 CI 的最低 Go 版本，再把一个基准函数完整改为 for b.Loop()，最后用相同输入、相同命令重复测量。只要不混用循环控制，准备与清理位置清楚，迁移后的结果就更容易解释。