并行基准测试能否直接改用 B.Loop

不能把并行基准测试里的 pb.Next() 机械替换成 b.Loop()。B.Loop 适合普通基准函数的测量循环；RunParallel 回调拿到的是 *testing.PB，它负责把总迭代次数分配给多个 goroutine。需要迁移的是普通基准的循环写法，并行基准应继续保留 RunParallel 和 PB.Next。

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

B.Loop 和 PB.Next 解决的不是同一个问题

传统普通基准通常写成 for i := 0; i 。Go 1.24 引入 B.Loop 后，可以把被测代码放进 for b.Loop()，由 testing 包处理计时启动，并降低编译器把无副作用调用优化掉的风险。它的接收者是 *testing.B，循环上下文只有一个基准函数。

并行基准的核心则是 b.RunParallel。testing 包创建多个 goroutine，并通过每个回调收到的 *testing.PB 让各 worker 反复调用 pb.Next()。PB.Next 不只是“判断循环是否结束”，还参与总迭代次数的分配。因此，问题不在于两个名字不同，而在于它们属于两套测量和调度契约。

普通基准可以这样迁移到 B.Loop

如果原测试没有调用 RunParallel，迁移通常只改循环控制。昂贵的输入构造放到循环前，清理放到循环后；这样更符合 B.Loop 对测量区间的定义。

func BenchmarkEncode(b *testing.B) {
	// 输入只准备一次，避免把初始化开销算进每次操作。
	input := []byte("sample payload")
	b.ReportAllocs()

	for b.Loop() {
		// 循环体才是需要比较的编码操作。
		_ = encode(input)
	}
}

这类改写不等于“B.Loop 会让代码并行”。它只改变单个基准函数如何确定测量循环；如果被测对象本身有共享状态，仍需自行保证同步和结果可用。

并行基准继续使用 RunParallel

并行场景应保留 PB.Next，并把 goroutine 私有的缓冲区、客户端或临时对象放在回调内部。非 CPU 密集型任务可以用 SetParallelism 调整 worker 数量，但参数改变后要重新解释结果，不能把一次运行的 ns/op 当成通用吞吐结论。

func BenchmarkParallelEncode(b *testing.B) {
	// 非 CPU 密集型工作才考虑提高默认 GOMAXPROCS 并行度。
	b.SetParallelism(2)
	b.RunParallel(func(pb *testing.PB) {
		// 每个 worker 独享缓冲区，避免无关的锁竞争。
		buf := make([]byte, 0, 128)
		for pb.Next() {
			// PB.Next 负责并行基准的迭代分配，不要换成 b.Loop。
			buf = encodeInto(buf[:0], []byte("sample payload"))
		}
	})
}

如果需要记录额外指标，应在 RunParallel 返回后统一汇总；并行回调中不要操作全局计时器。官方文档还特别提醒，RunParallel 的时间是整个并行基准的墙钟口径，不是把每个 goroutine 的耗时相加。

迁移前后的检查清单

还要确认构建环境支持 B.Loop：它从 Go 1.24 起可用。若项目仍需兼容更早工具链，不能只改测试文件，还要考虑构建约束或保留旧式基准实现。并行迁移的判断标准也不是“能不能编译”，而是迭代分配、计时范围和共享状态是否仍与原测试意图一致。

相关问题

并行基准里能否在每个 worker 内调用 b.Loop？

不建议也不能替代 PB.Next。worker 收到的是 *testing.PB，并行工作分配应由它完成；把 *testing.B 的循环引入回调会混淆迭代和计时口径。

RunParallel 还能使用 b.N 吗？

可以在回调结束后用于报告按总操作次数计算的自定义指标，但不要把它当作某一个 worker 的循环上限；各 worker 应通过 pb.Next 获取工作。

什么时候最适合采用 B.Loop？

当基准是单函数循环、需要把初始化和清理排除在计时外，或担心旧式循环中的编译器优化时，B.Loop 更合适；它不是并行调度 API。