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 来影响内层；每个子函数都得自己调。
- 兼容性风险：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() 就成了障眼法。