Go testing.B.Run 分离一次性准备与子基准结果的组织方法

写 Go 基准测试时，如果数据库种子、文件读取或大对象构造直接放在循环前后，最容易出现两个误判：准备成本被算进结果，或者基准框架为了寻找合适的 b.N 而重复调用整段准备代码。更稳妥的组织方式是让外层 Benchmark 只负责一次性准备，再用 testing.B.Run 建立真正被测的子基准。

官方文档：https://pkg.go.dev/testing#B.Run

为什么要把准备代码放在 b.Run 外层

testing.B.Run 的关键价值不是“多套一层函数”，而是把一次基准调用和多个可命名的子基准分开。外层基准调用可以完成样本加载、连接建立和公共对象构造；这些工作不应该随着每一次被测迭代重复。进入子基准后，框架只调整该子基准的 b.N，输出也会带上子基准名称。

最小配方：一次准备，多个命名子基准

下面用两种输入规模演示组织方式。样本切片在外层创建，子基准只负责把目标函数执行 b.N 次。示例中的注释说明了计时边界和资源清理意图，读者可以替换成自己的解析、查询或序列化函数。

func BenchmarkDecode(b *testing.B) {
	// 这部分只准备一次，不把样本构造成本混入每次迭代。
	small := loadFixture(256)
	large := loadFixture(4096)

	b.Run("256B", func(b *testing.B) {
		// 子基准只测 decode，清理动作不会进入后续迭代。
		b.ResetTimer()
		for i := 0; i 

如果准备动作本身也需要测量，应为它建立另一个明确命名的子基准，而不是把它偷偷留在被测循环外。这样输出中的 Decode/256B 与 Decode/4KiB 才有可比含义。

用参数表扩展场景，保持结果可读

场景超过两个时，可以先定义参数表，再统一调用 b.Run。名称应包含读者真正关心的差异，例如字节数、编码格式或查询规模，不要只使用 case1、case2。每个回调都拥有自己的 *testing.B，不要在闭包中修改外层的迭代计数。

运行与排查清单

先用下面的命令确认名称和内存分配是否符合预期：

# 只运行名称含 Decode 的基准，并显示每次操作的分配数据。
go test -run '^$' -bench 'Decode' -benchmem ./...

若准备成本仍出现在结果中，检查它是否写进了 b.Run 回调或计时器是否在准备完成前启动。若两个场景结果互相影响，优先检查共享切片、复用缓冲区和闭包捕获变量。RunParallel 是另一种并发模型，官方说明其回调不应调用有全局影响的 StartTimer、StopTimer 或 ResetTimer；这篇的组织方式针对串行子基准。

相关问题

b.Run 会让外层基准也产生一行结果吗？

当基准至少调用一次 Run 时，外层函数本身不作为独立测量对象，输出重点是各个子基准。应把名称和场景信息写进子基准名。

准备代码必须只执行一次吗？

只对不属于被测操作的昂贵准备这样组织。若准备本身就是测试目标，就单独命名并测量它，不能为了好看而排除真实成本。

可以在 b.Run 里再调用 RunParallel 吗？

可以把它作为独立场景设计，但需要重新定义共享状态、计时和结果含义；不要把串行子基准的计时规则原样套到并发回调中。