b.ResetTimer() 必须放在 b.Run() 内部子函数开头，因为其仅重置计时器而不重置迭代次数，若放外部会将初始化等 setup 阶段计入耗时，导致结果偏高且不可比；Go 1.21+ 起更要求每个子 benchmark 独立调用。

为什么 b.ResetTimer() 不能放在 b.Run() 外面

因为 b.ResetTimer() 只重置计时器，不重置迭代次数或基准测试上下文；如果在 b.Run() 外调用，它会把 setup 阶段（比如初始化、预热）也计入耗时，导致测出来的是“带初始化的总时间”，不是你真正想看的核心逻辑。

• 常见错误现象：BenchmarkFoo-8 1000000 1200 ns/op 数值明显偏高，且多次运行波动大
• 正确位置：必须在 b.Run() 的子函数内部、实际被测逻辑之前调用
• 典型误用：b.ResetTimer() 放在 b.Run("name", func(b *testing.B) { ... }) 外层

b.ResetTimer() 和 b.StopTimer() / b.StartTimer() 的分工

三者不是替代关系，而是配合使用：如果你的 benchmark 里有「不可省略但不该计入耗时」的操作（比如生成输入数据），就用 b.StopTimer() + b.StartTimer() 控制区间；b.ResetTimer() 是重置起点，只该用一次，且仅用于排除 setup 影响。

• b.StopTimer()：暂停计时，适合数据准备、状态预设等非核心逻辑
• b.StartTimer()：恢复计时，必须和 b.StopTimer() 成对出现
• b.ResetTimer()：清零已累计时间，通常只在 b.Run 子函数开头调用一次
• 性能影响：频繁调用 b.ResetTimer() 不会报错，但会让结果失去可比性——每次重置都丢弃前面所有采样

Go 1.21+ 中 b.ResetTimer() 在 b.Run() 嵌套下的行为变化

从 Go 1.21 开始，b.ResetTimer() 在嵌套 b.Run() 中不再自动继承父级计时状态，每个子 benchmark 独立计时。这意味着你不能再依赖外层 ResetTimer 来影响内层；每个子函数都得自己调。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 兼容性风险：Go 1.20 及之前版本中“外层 Reset，内层自动生效”的写法，在 1.21+ 里会误把 setup 时间算进去
• 正确写法：每个 b.Run("xxx", func(b *testing.B) { ... }) 内部第一行就是 b.ResetTimer()
• 示例片段：

  func BenchmarkParseJSON(b *testing.B) {
      data := makeTestData() // 这部分不测
      b.Run("std", func(b *testing.B) {
          b.ResetTimer() // 必须放这里
          for i := 0; i < b.N; i++ {
              json.Unmarshal(data, &v)
          }
      })
  }

容易被忽略的冷知识：循环体外的变量初始化是否要 b.StopTimer()

要看变量是否依赖 b.N 或随迭代变化。如果只是固定初始化（比如全局缓存、一次分配的 slice），放在 b.Run 外是安全的；但如果每次迭代都要新造输入（如 make([]byte, i)），就必须包在 b.StopTimer()/b.StartTimer() 里，否则会污染测量结果。

立即学习“go语言免费学习笔记（深入）”；

• 反例：for i := 0; i —— <code>generateInput 必须停表
• 正例：buf := make([]byte, 1024); b.Run(..., func(b *testing.B) { for i := 0; i —— <code>buf 分配在外部没问题
• 调试技巧：加 b.ReportAllocs() 后观察 allocs/op 是否异常高，常能反推是否有不该计时的分配混进循环体

实际写 benchmark 时，最常出问题的不是语法，而是没想清楚“到底想测哪一段”——一旦 setup 和核心逻辑边界模糊，b.ResetTimer() 就成了障眼法。