必须在基准测试中真正要测量的代码执行前调用b.ResetTimer()，以跳过初始化、预热等非被测逻辑耗时；它须在b.N循环开始前调用，不可在循环内重复调用。
什么时候必须调用 b.ResetTimer()
在 Go 的基准测试（go test -bench）中，b.ResetTimer() 用于重置计时器，**跳过初始化或预热阶段的耗时统计**。如果你的 BenchmarkXxx 函数里做了非被测逻辑（比如构造大对象、预分配内存、建立连接、填充缓存），又不希望这些时间被计入最终的 ns/op，就必须在真正要测量的代码前调用它。
常见错误是：把 setup 代码写在 b.ResetTimer() 之前却没调用它，导致初始化耗时被摊入结果，尤其在循环多次运行（b.N）时，误差会被放大。
- 预热 map 或 slice 到稳定状态（避免扩容干扰）
- 加载配置、解析模板、编译正则表达式等一次性开销
- 启动本地 HTTP server 或 mock DB 连接（仅限单测环境）
- 读取测试文件并解码为结构体（文件 I/O 不属于被测函数性能）
b.ResetTimer() 必须在 b.N 循环开始前调用
Go 基准测试框架会在内部循环执行你的逻辑 b.N 次，并累加总耗时。计时器默认从函数入口开始计时；一旦调用 b.ResetTimer()，后续所有时间才会计入报告。它不能在循环体内反复调用（会重置每次迭代的计时起点，导致结果归零或异常）。
正确姿势是：setup → b.ResetTimer() → for i := 0; i { 被测逻辑 }。
立即学习“go语言免费学习笔记（深入）”；
func BenchmarkMapAccess(b *testing.B) {
// 预热：构建一个含 10000 个 key 的 map
m := make(map[string]int)
for i := 0; i < 10000; i++ {
m[fmt.Sprintf("key-%d", i)] = i
}
// ✅ 关键：重置计时器，排除 build map 的耗时
b.ResetTimer()
// ✅ 在 b.N 循环中只放真正要测的操作
for i := 0; i < b.N; i++ {
_ = m["key-5000"]
}
}
和 b.StopTimer() / b.StartTimer() 的区别
b.ResetTimer() 是“清零并重启”，而 b.StopTimer() 和 b.StartTimer() 是成对使用的暂停/恢复机制，适合需要在循环中穿插非测量逻辑的场景（比如每次迭代前 reload 数据，但 reload 不该算进耗时）。
-
b.ResetTimer()：只能调用一次，且必须在循环前 —— 简单粗暴，覆盖绝大多数情况 -
b.StopTimer()+b.StartTimer()：可多次，适合复杂 benchmark，例如：for i := 0; i - 误用
b.ResetTimer()在循环内会导致每次重置，ns/op可能趋近于 0 或出现负值（Go 1.21+ 会 panic）
容易被忽略的细节
很多人以为 b.ResetTimer() 会自动处理 GC 或调度抖动，其实不会。它只是重置计时器，不影响运行时行为。如果你的被测逻辑触发了大量 GC，或者依赖外部服务响应时间不稳定，b.ResetTimer() 解决不了这些问题 —— 此时应结合 b.ReportAllocs()、多次运行取中位数、或用 runtime.GC() 手动触发 GC 来减少噪音。
另外，如果 benchmark 中用了 time.Sleep() 或阻塞 channel 操作，即使在 b.ResetTimer() 后，也会被计入耗时 —— 因为那是你代码的真实延迟，不是 setup 开销。
