Golang基准测试中重置计时器的正确方式

必须用 b.ResetTimer() 是因为基准测试应只测量核心逻辑的真实开销，而非初始化等准备时间；它须紧接准备工作之后、循环开始之前调用，否则计时包含无关开销导致结果失真。

为什么必须用 b.ResetTimer()？

基准测试不是测“整个函数耗时”，而是测“核心逻辑的真实开销”。初始化数据、构造对象、预热缓存这些操作，本不该计入性能指标——但默认情况下，go test -bench 会从函数入口就开始计时。不重置，结果就变成“准备时间 + 真实耗时”，尤其当初始化耗时远大于被测逻辑（比如加载 10MB 配置或建连接），ns/op 就完全失真。

b.ResetTimer() 应该放在哪儿？

它必须紧接在所有准备工作之后、循环开始之前。顺序错了，等于没重置。

• ✅ 正确：初始化 → b.ResetTimer() → for i := 0; i
• ❌ 错误：初始化 → for i := 0; i （每次循环都重置，计时不连续）
• ❌ 错误：b.ResetTimer() 放在循环里最外层、但初始化还在它后面（计时已包含初始化）

func BenchmarkSum(b *testing.B) {
    nums := make([]int, 1000)
    for i := range nums {
        nums[i] = i
    }
    b.ResetTimer() // ✅ 就在这里
    for i := 0; i < b.N; i++ {
        sum := 0
        for _, v := range nums {
            sum += v
        }
        _ = sum // 防止编译器优化掉计算
    }
}

比 ResetTimer 更精细的控制：何时用 StopTimer 和 StartTimer？

当被测逻辑本身需要“准备 → 执行 → 清理”三段式，且只有中间执行段要计时（比如每次循环都要重置一个临时 map、跑一次查询、再删掉），就不能只靠一次 ResetTimer。这时要用配对的 b.StopTimer() 和 b.StartTimer()。

• b.StopTimer() 暂停计时（不重置已累计时间）
• b.StartTimer() 恢复计时（继续累加）
• 典型场景：测试带状态清理的循环逻辑、模拟请求-响应-归还资源流程

func BenchmarkWithCleanup(b *testing.B) {
    cache := make(map[string]int)
    for i := 0; i < b.N; i++ {
        b.StopTimer()
        // 准备：清空并填充 cache
        clear(cache)
        for j := 0; j < 100; j++ {
            cache[fmt.Sprintf("key%d", j)] = j
        }
        b.StartTimer()

        // 执行：只测查找
        _ = cache["key42"]

        b.StopTimer()
        // 清理：可选，不影响计时，但保持状态干净
        delete(cache, "key42")
        b.StartTimer()
    }
}

容易被忽略的三个坑

很多人写了 ResetTimer 还是测不准，问题往往出在这些细节上：

• 忘了把返回值赋给变量（如 _ = fn()），导致 Go 编译器直接优化掉整行调用，ns/op 趋近于 0 —— 这不是快，是没测
• 在循环里重复创建大对象（如 make([]byte, 1e6)），这部分内存分配会被计入 B/op 和 allocs/op，但实际业务中对象可能是复用的；应提前提前初始化
• 没加 -benchmem 参数，看不到内存分配情况，而很多性能退化其实源于隐式堆分配，不是 CPU 时间暴涨

重置计时器本身很简单，难的是判断“哪些代码属于准备、哪些属于真正要测的逻辑”——这需要你对被测函数的职责边界有清晰认知，而不是机械套用模板。