ResetTimer 必须在基准测试中初始化和非被测逻辑之后、实际性能测量循环之前调用，以排除初始化等无关开销对计时结果的影响。
ResetTimer 什么时候必须调用
在 testing.B 的基准测试中，ResetTimer 不是“可选优化”，而是**控制计时范围的核心开关**。如果你的 Benchmark 函数里做了初始化（比如构建大 slice、打开文件、预热 map）、或包含非被测逻辑（如日志打印、结果校验），这些耗时会被默认计入总时间——导致结果严重失真。
典型错误写法：
func BenchmarkBad(b *testing.B) {
data := make([]int, 1000000) // 初始化开销被计时了
for i := range data {
data[i] = i
}
for i := 0; i < b.N; i++ {
sum := 0
for _, v := range data {
sum += v
}
}
}
上面的 make 和初始化循环实际占用了大量时间，但你真正想测的是“遍历求和”这个操作。
ResetTimer 正确调用位置
ResetTimer 必须在所有**一次性前置工作完成后、进入循环前立即调用**。它会把当前已累计的纳秒数清零，后续 b.N 次迭代才开始真实计时。
立即学习“go语言免费学习笔记（深入）”；
- 不能放在循环内部（会导致每次迭代都重置，最终时间趋近于 0）
- 不能放在循环之后（毫无意义）
- 如果有多阶段预热（比如先 warmup cache 再正式测），可在每阶段后按需调用，但通常只需一次
修正后的写法：
func BenchmarkGood(b *testing.B) {
data := make([]int, 1000000)
for i := range data {
data[i] = i
}
b.ResetTimer() // ✅ 关键：重置计时器，排除初始化干扰
for i := 0; i < b.N; i++ {
sum := 0
for _, v := range data {
sum += v
}
}
}
ResetTimer 和 StopTimer / StartTimer 的区别
ResetTimer 是“清零并继续计时”，而 StopTimer/StartTimer 是“暂停/恢复计时”。三者适用场景不同：
-
ResetTimer：适合单次初始化后批量测量（最常用） -
StopTimer+StartTimer：适合需要穿插非测量逻辑的复杂流程，比如每次迭代中都要做一次 setup/cleanup
例如，每次迭代都要新建一个 sync.Pool 并清理，又不想把 pool 创建/销毁算进性能数据：
func BenchmarkWithSetup(b *testing.B) {
for i := 0; i < b.N; i++ {
b.StopTimer()
pool := sync.Pool{New: func() any { return &bytes.Buffer{} }}
b.StartTimer()
// 实际被测逻辑
buf := pool.Get().(*bytes.Buffer)
buf.WriteString("hello")
pool.Put(buf)
}
}
ResetTimer 调用后还能改 b.N 吗
不能。一旦调用 b.ResetTimer()，b.N 就已由 go test 确定并锁定。后续修改 b.N 不会影响本次运行的迭代次数，也不会触发重新采样——它只是个只读字段。
更关键的是：ResetTimer 不会重置 b.N，也不会影响内存分配统计（b.ReportAllocs() 仍统计整个函数生命周期）。如果初始化阶段有大量临时分配，它们仍会计入 allocs/op，这时得靠 b.StopTimer 配合手动控制。
容易忽略的一点：Go 1.21+ 对 ResetTimer 做了优化，但如果在 init() 或包级变量初始化里做了重型操作，那些开销依然无法被 ResetTimer 排除——得挪到 benchmark 函数内，并在 ResetTimer 前完成。
