Go benchmark Timer 怎样排除初始化对比压测结果

Go 基准测试里最容易混入结果的不是目标函数，而是目标函数之前的初始化。如果每轮都把创建输入、填充缓存或分配临时对象算进计时，最后看到的 ns/op 就不再只代表被测操作。使用 testing.B 时，b.N 风格可以在初始化后调用 b.ResetTimer()；需要分段测量时用 b.StopTimer() 与 b.StartTimer()。新代码也可以使用 b.Loop()，它会在首次进入循环时自动重置计时。

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

最小原则：初始化放在计时边界外；b.N 风格在初始化后重置计时，分阶段代码用 StopTimer/StartTimer；采用 B.Loop 时不要重复手动重置同一段边界。

为什么初始化会污染 ns/op

传统基准函数会被框架多次调用，并逐步调整 b.N，直到运行时间足够稳定。若初始化写在循环前却没有重置计时，第一次和后续试运行的初始化成本都会进入统计区间，尤其是切片扩容、编码器创建和大输入构造，会让两段代码的比较失去同一口径。

要比较的是“每次目标操作”的成本，就要把一次性准备和重复执行分开。ResetTimer 不只是把耗时归零，也会清零基准的内存分配计数和用户自定义指标；它不会改变计时器当前是否开启。

使用 ResetTimer 排除一次性初始化

在 b.N 风格中，把初始化放在循环前，完成后调用一次 b.ResetTimer()，再进入目标循环。下面的写法比较字符串拼接的重复成本，输入构造只发生在计时边界外。

func BenchmarkJoin(b *testing.B) {
	parts := []string{"go", "benchmark", "timer"}
	buf := make([]string, len(parts))
	copy(buf, parts) // 只准备一次输入，不把准备成本放进结果

	b.ResetTimer() // 清零耗时、分配计数和用户指标
	for i := 0; i 

示例需要导入 strings 和 testing。如果初始化本身就是要比较的对象，就不要把它移出计时区间；关键不是“永远排除初始化”，而是让每个候选方案使用相同的测量定义。

需要分段时用 StopTimer 和 StartTimer

有些基准不只有一个连续循环。例如每轮开始前要刷新输入，或测量区间之间要做一次状态清理。这时可以暂时停止计时，完成不计入结果的动作，再恢复计时。StopTimer 会暂停计时，StartTimer 会从当前位置继续；两者不会替你清零之前已经累计的耗时。

func BenchmarkDecode(b *testing.B) {
	data := []byte(`{"name":"go"}`)
	for i := 0; i 

这种写法适合明确的分段边界，但不要在很短的操作中频繁开关计时器，否则计时控制本身会让代码难读。若初始化只发生一次，优先使用一次 ResetTimer；若每轮都需要准备独立输入，再考虑暂停每轮的准备阶段。

B.Loop 会自动处理新的循环边界

当前 Go 官方文档建议新基准优先考虑 b.Loop()。它第一次被调用时会重置计时，因此循环前的初始化不会计入测量；当循环结束时，它也会停止计时，后面的清理不会计入结果。

func BenchmarkJoinLoop(b *testing.B) {
	parts := []string{"go", "benchmark", "timer"}
	for b.Loop() {
		_ = strings.Join(parts, ":") // B.Loop 只测量循环体
	}
}

如果项目需要兼容较旧的 Go 工具链，继续使用 b.N 与 ResetTimer；如果已经采用支持 B.Loop 的工具链，优先保持循环结构简单，不要在 B.Loop 前后再叠加一套重复的手动计时边界。

比较两个基准时检查这四项

1. 输入是否一致：两个基准使用同样的数据规模、内容和预热条件。
2. 初始化是否同口径：一次性初始化要么都排除，要么都纳入，不能只给其中一个候选调用 ResetTimer。
3. 指标是否一致：同时观察 ns/op 与 allocs/op；重置计时会重置分配计数，不能把不同边界的数字直接对比。
4. 命令是否一致：用同一组 go test -bench 参数、相同 -benchtime 和相同硬件环境，再用多次结果判断趋势。

常见问题

ResetTimer 会停止基准计时吗？

不会。它清零已经累计的耗时、分配计数和用户指标；计时开关保持原状态。需要暂停时用 StopTimer，需要继续时用 StartTimer。

初始化一定要排除吗？

不一定。如果真实业务的单次请求确实包含初始化，就应把它纳入测量；但比较多个实现时必须明确相同的边界，避免一个方案测冷启动、另一个方案测热路径。