写了多年 Go Benchmark，为什么你应该用 b.Loop() ？

在 Go 语言中，基准测试（Benchmark）是衡量代码性能的标准方式。然而，传统的基准测试写法不仅繁琐，而且容易受到编译器优化的干扰，导致测试结果失真。

Go 1.24 引入了全新的 testing.B.Loop()，彻底简化了基准测试的书写方式并提升了准确性。

传统写法两大痛点：编译器优化与计时器混乱

在传统写法中，开发者常面临编译器死代码消除（DCE）的干扰。若循环内调用的函数结果未被使用，编译器会直接将其删除，导致测试耗时偏低。

此外，如果测试前有复杂的初始化操作，开发者还必须频繁且小心地手动调用计时器控制方法，增大了心智负担。

下面是一段传统的基准测试代码：

var sink int

func BenchmarkClassic(b *testing.B) {
	setupExpensiveData()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		sink = processString("42")
	}
}

上述写法中，全局变量 sink 仅用于防止编译器将 processString 优化掉，而 b.ResetTimer() 用以剔除 setupExpensiveData() 的耗时。

新写法 b.Loop()：准确且优雅

Go 1.24 推出的 b.Loop() 完美解决了上述问题。开发者只需将 for b.Loop() 作为循环条件，即可实现自动活性保证与自动计时。

示例代码如下：

func BenchmarkLoop(b *testing.B) {
	setupExpensiveData()
	for b.Loop() {
		processString("42")
	}
}

在使用 b.Loop() 后，代码具有以下三点显著优势：

• 自动活性保证：编译器在底层会自动保持循环体内所有变量及返回值的活跃状态，无需再定义多余的全局 sink 变量。
• 自动管理计时：在第一次调用 b.Loop() 时，引擎会自动重置计时器；在循环结束时，引擎会自动停止计时，确保初始化与清理开销不被计入。
• 更高效的运行模式：相比传统写法需要反复调整 b.N 进行校准，b.Loop() 运行模型能一次性精准推算性能指标。

底层避坑指南：早期版本的内存逃逸陷阱

虽然 b.Loop() 解决了编译器过度优化的问题，但在 Go 1.24 刚推出时也曾伴随过一个隐蔽的编译器缺陷（Go Issue #73137）。

由于编译器为了保持变量活跃，在底层生成的临时变量作用域偏大，这会导致部分本应在栈上分配的局部变量被错误地判定为逃逸到堆上，从而在 Benchmark 运行时产生了意外的堆分配（Heap Allocations）。

该缺陷在后续的 Go 补丁版本（及 1.25/1.26 以后）中得到了修复。因此，强烈建议在使用 b.Loop() 编写涉及微观内存分配的测试时，升级至最新的 Go 小版本以规避此问题。

进阶用法与单一循环规则

每个 Benchmark 函数内部只能存在一个 for b.Loop() 循环。如果在一个测试函数内多次或嵌套调用 b.Loop()，将会触发运行时恐慌。

如果在迭代内仍有需要剔除的微小开销，可以配合 b.StopTimer() 和 b.StartTimer()：

func BenchmarkIterControl(b *testing.B) {
	for b.Loop() {
		b.StopTimer()
		temp := getIterData()
		b.StartTimer()
		processString(temp)
	}
}

上述代码在每次迭代的数据准备阶段暂停计时，确保仅统计 processString 的耗时。

写在最后

Go 1.24 的 b.Loop() 不仅仅是语法上的微调，更是对 Go 语言基准测试底层设计的一次正规化重构。它通过与编译器的深度绑定，终结了由于死代码消除导致的“假性能”乱象，也将开发者从手动计时器管理的琐碎心智负担中解放出来。

尽管全面向新写法过渡可能需要一些时间，但在 Go 语言持续演进的背景下，拥抱 b.Loop() 无疑能为团队换来更加纯粹、精准、高效的代码度量标准。如果项目已经全面切换到 Go 1.24 或更高版本，建议逐步重构那些老旧的 Benchmark 写法，让基准测试回归其应有的真实价值。