b.ResetTimer() 是“归零重来”而非暂停计时，它清零已累计耗时与内存分配次数并立即重启计时；必须在被测核心逻辑前显式调用，defer 方式无效。
为什么 b.ResetTimer() 不是“暂停计时”，而是“归零重来”
b.ResetTimer() 的真实行为，不是暂停或跳过某段代码，而是把当前已累计的耗时和内存分配次数**全部清零**，并立刻开始新一轮计时与统计。它不改变迭代次数 b.N，也不影响后续循环执行逻辑——只是让“秒表”从 0 重新跑。
常见错误现象：有人在 for 循环外写 defer b.ResetTimer()，结果完全没效果。因为 ResetTimer() 必须显式调用，且只对它之后的代码生效；defer 会延迟到函数返回时才执行，此时基准循环早已结束。
- 初始化数据、打开文件、构建大 map 等操作，必须放在
b.ResetTimer()之前 - 被测核心逻辑（如加密、排序、序列化）必须放在
b.ResetTimer()之后，并在for i := 0; i 循环内执行 - 若忘记调用，
ns/op里就混着初始化时间——比如加载 5MB 配置花了 8ms，而实际处理只用 200ns，结果却显示 “8,200,000 ns/op”
什么时候必须用 b.ResetTimer()？看这三种典型场景
不是所有基准测试都需要它，但只要出现以下任一情况，不用就大概率测歪了：
-
构造代价高的输入：比如每次生成 10 万个随机字符串再排序，生成过程应放
ResetTimer()前，排序逻辑放之后 -
依赖外部状态预热：如首次调用
json.Marshal会触发类型反射缓存填充，这部分开销属于“冷启动”，应排除 -
需要复用资源但不能共享：例如每个迭代需独立的
sync.Pool或临时目录，创建池/目录放 reset 前，取用+归还放 reset 后
反例：直接在 BenchmarkFoo 开头 new 一个结构体，然后 for 循环里反复调它的方法——如果 new 花了 1μs，而方法本身只要 5ns，那 99.5% 的时间都在测内存分配器，不是你的逻辑。
b.ResetTimer() 和编译器优化的对抗关系
即使你正确重置了计时器，Go 编译器仍可能把“看起来没用”的计算整个删掉——比如 result := expensiveComputation(); _ = result，某些版本下仍会被优化掉。
- 务必把关键结果赋给全局变量或传给
blackhole函数（标准做法：testing.B提供b.ReportAllocs()，但防优化得靠人肉） - 推荐写法：
result := yourFunc(); blackhole(result)，其中var blackhole = func(x interface{}) {}，确保副作用不可省略 -
b.ResetTimer()本身不防优化，它只管计时边界；防优化是另一层必须手动补上的防护
并行基准测试中 b.ResetTimer() 的特殊性
在 b.RunParallel 场景下，b.ResetTimer() 的行为容易被误解：它只作用于当前 goroutine 的本次执行片段，且**每个并行 worker 都有自己的计时上下文**。
- 不能在
RunParallel回调外调用ResetTimer()，否则无效 - 正确位置是在 parallel 回调内部、真正干活前，例如：
func(b *testing.B) { // 准备共享资源（如读取配置） cfg := loadConfig() b.ResetTimer() // ✅ 这里重置，影响后续所有 parallel worker 的计时起点 b.RunParallel(func(pb *testing.PB) { for pb.Next() { process(cfg) // 每个 worker 测的是 process 的真实耗时 } }) } - 若在
pb.Next()循环内反复调用ResetTimer()，会导致计时断续、结果失真——它不是 per-iteration 控制，而是 per-benchmark-function 控制
最易被忽略的一点：重置只清除时间和 alloc 计数，但不重置 GC 状态、不清理 CPU 缓存、也不隔离 goroutine 调度干扰。哪怕 b.ResetTimer() 用对了，单次运行仍可能因后台进程抖动产生 10–20% 波动，所以一定要用 -count=5 -benchtime=10s 多轮取平均。
