Go benchmark.ResetTimer 什么时候应该调用

Go 基准测试里，b.ResetTimer() 通常应该放在一次性准备工作完成之后、b.N 循环开始之前。这样 ns/op 主要反映目标操作，而不是输入构造、文件解析或对象初始化的耗时。它只会把已累计的计时和内存分配计数清零，不会替你启动或停止计时。

为什么准备代码会污染 benchmark 结果

传统的 b.N 基准会被测试框架多次调用，逐步调整迭代次数，直到测量足够稳定。假设我们要比较 strings.Builder.WriteString，却把大字符串生成、Builder 初始化和容量预留都写在循环前。如果不重置计时，这些准备阶段的时间会混进本轮结果；当准备工作很重时，读者看到的就不再是写入操作的平均成本。

一次性准备完成后，放在循环前最稳妥

下面的写法把“准备输入”和“测量写入”分成两个区域。代码块里的注释说明了为什么要在循环前重置，而不是逐行解释语法。

func BenchmarkBuilderWrite(b *testing.B) {
	// 这部分只准备被测操作要使用的固定输入，不计入 ns/op。
	text := strings.Repeat("go", 128)
	builder := strings.Builder{}
	builder.Grow(len(text))

	// 清掉准备阶段的耗时和分配计数，计时器本身仍保持运行状态。
	b.ResetTimer()
	for i := 0; i 

这里的判断标准不是“代码写在循环外就一定不计时”，而是“这段开销是否属于本次性能问题”。如果你的目标是测量完整的输入构造流程，就不要把它排除；如果只比较写入阶段，才在准备完成后调用 ResetTimer。

ResetTimer、StopTimer 和 StartTimer 分别解决什么问题

ResetTimer 不改变计时器是否正在运行。因此在计时已经停止时调用它，只是清零累计值，之后仍需显式 StartTimer 才会继续计时。反过来，如果只是想临时跳过某段清理或日志操作，使用 StopTimer 与 StartTimer 更能表达意图。

三个容易误用的边界

第一，不要把 ResetTimer 放进循环里，否则每次迭代都会抹掉前面的累计时间，输出无法代表完整样本。第二，使用 b.Run 划分子基准时，每个子基准有自己的测量上下文，应把各自的 setup 放在对应回调里，不要试图用父基准的计时器统一覆盖。第三，b.RunParallel 的 worker 不应调用 ResetTimer、StartTimer 或 StopTimer，因为这些方法具有全局效果，可能互相干扰。

func BenchmarkLookup(b *testing.B) {
	// 子基准各自准备数据，名称用于输出中区分不同输入规模。
	b.Run("small", func(b *testing.B) {
		items := makeItems(32)
		b.ResetTimer()
		for i := 0; i 

如果项目的最低 Go 版本支持 B.Loop，新基准也可以写成 for b.Loop() { ... }。官方说明它首次进入循环时会重置计时，并在循环结束后停止计时；这时不要再同时维护一套 b.N 循环。

怎样确认测量边界确实符合目标

先用 go test -bench BenchmarkBuilderWrite -benchmem ./... 观察 ns/op、B/op 和 allocs/op，再把 ResetTimer 临时移除做一次对照。对照只能帮助理解边界，不能把两次不同环境的绝对数字当成严格结论；正式比较还应固定输入、编译选项和运行环境。

相关问题

ResetTimer 会重置 b.N 吗？

不会。它清零测量数据，不改变框架安排的迭代次数。

准备工作每轮都要做，应该调用 ResetTimer 吗？

如果准备工作就是要测的用户场景，应把它放入循环并保留在计时范围内；不要为了得到更小的数字而重置。

为什么 RunParallel 里不能重置计时器？

并行 worker 共用基准的计时上下文，单个 worker 重置会影响整体测量；把线程本地准备放在 worker 外或按官方并行模式组织。

参考：https://pkg.go.dev/testing；Go 官方包文档对 ResetTimer、RunParallel、B.Loop 的语义和边界有完整说明。