Go testing.B 如何区分初始化时间和基准循环时间

Go 基准测试里，初始化时间和基准循环时间要分开看。输入构造、缓存预热、文件读取等一次性准备应放在循环前；如果仍使用 b.N 风格，就在准备完成后调用 b.ResetTimer()。这样 ns/op 主要反映被测操作，而不是反映“准备一大块数据花了多久”。

为什么 b.N 风格需要主动重置计时器

传统基准函数通常由 testing 包多次调用，并逐步调整 b.N，直到运行时间足够稳定。因此，循环前的准备代码可能跟着调用重复执行。准备阶段既会污染结果，也可能让不同轮次的输入规模不一致。

典型的边界写法如下，ResetTimer 放在所有一次性准备之后、真正的基准循环之前：

func BenchmarkLookup(b *testing.B) {
    // 这部分只准备输入，不作为查找操作的计时结果。
    data := makeIndex(10000)
    key := "user-9000"

    b.ResetTimer()
    for i := 0; i 

不要把 ResetTimer 写进循环，也不要在重置后继续做大量“准备工作”。它清除的是当前累计计时和已记录的分配统计，重点是把测量起点放在明确的位置。

StopTimer 和 StartTimer 该放在什么位置

有些准备动作发生在每次迭代里，但它们不是本次性能问题的一部分。例如每轮都要生成随机请求、清空测试缓冲区，或者把结果写入一个只用于防止编译器优化的容器。这时可以暂时停止计时：

func BenchmarkEncode(b *testing.B) {
    input := []byte("a small payload")
    var sink []byte

    for i := 0; i 

如果暂停和恢复本身比目标操作还重，结果会变得不稳定。优先把可复用的准备移到循环外；只有确实无法移动时，才使用这组 API。读取计时器状态的代码也应保持简单，别在测量区加入日志。

新代码为什么优先考虑 B.Loop

当前 testing 文档建议新基准优先使用 b.Loop。它把“循环体就是被测内容”的意图表达得更直接，循环前的昂贵准备不会计入循环体测量，也不需要手动维护 b.N。迁移时仍要检查循环体：不要把随机数生成、网络请求或无关清理混进去。

func BenchmarkLookupLoop(b *testing.B) {
    // B.Loop 外的初始化不属于循环体测量。
    data := makeIndex(10000)
    key := "user-9000"

    for b.Loop() {
        // 这里保持为单一、可重复的目标操作。
        _ = data[key]
    }
}

一张表判断该用哪个计时 API

最后用 go test -run '^$' -bench 'BenchmarkLookup' -benchmem 运行目标基准。不要只看一次输出；固定机器负载和输入后，多跑几次，再用 benchstat 比较两组结果。若初始化量本身就是要评估的对象，就不要重置计时，而应在标题和结论里明确“测的是端到端准备加执行”。

常见问题

ResetTimer 会不会把 b.N 重置为零？

不会。它调整的是计时起点和相关统计，不负责改变循环次数。

StopTimer 后忘记 StartTimer 会怎样？

后续操作可能不计时，结果就失去比较意义。把暂停区缩到最小，并让成对调用紧挨着出现。

有了 B.Loop 还需要 ResetTimer 吗？

普通场景通常不需要；如果循环外仍有额外的计时控制需求，应先确认问题是否更适合拆成两个基准。