B.Loop 中修改循环外变量为什么会影响基准结果

先说结论：testing.B.Loop 会控制迭代次数、自动处理循环前后的计时边界，并帮助阻止循环体被编译器整体优化掉，但它不会在每轮开始前复制或恢复循环外变量。只要循环体修改了外部切片、map、缓冲区或对象字段，下一轮就会从修改后的状态继续执行；一旦输入规模、容量、命中率或分支条件随轮次变化，最终的 ns/op 和 allocs/op 就成了多种工作量的平均值。

官方文档：https://pkg.go.dev/testing#B.Loop

循环外变量为什么会让每轮工作量漂移

Go 官方对 B.Loop 的要求很明确：循环的每次迭代应当做相同的事情。这里的“相同”不只指调用了同一个函数，还包括输入状态、数据规模和资源条件应当具有同一语义。B.Loop 第一次被调用时重置计时器，返回 false 时停止计时；这些动作不会回滚你的切片长度、map 内容或对象字段。

最典型的问题是把目标切片声明在循环外，然后在循环中持续 append：

func BenchmarkAppendDrift(b *testing.B) {
    chunk := make([]byte, 128)
    dst := make([]byte, 0, 1024)

    for b.Loop() {
        // 错误点：dst 的 len、cap 和底层数组会跨迭代保留并持续变化。
        dst = append(dst, chunk...)
    }
}

前几轮可能直接写入预留容量，某些轮次会触发扩容和复制，后续数据又会继续增长。这不仅让每轮工作量不一致，还可能让基准占用大量内存。类似的漂移还包括：循环外 map 从插入新键逐渐变成更新旧键；缓存从冷启动逐渐变成高命中；解码器、压缩器或 bytes.Buffer 复用后保留了更大的容量。

先决定要测新建成本还是复用成本

修复方法不是机械地把所有变量移进循环，而是先写清楚目标：生产代码每次都会创建新对象，还是会重置并复用同一个对象？这两种基准都可以正确，但名称、初始化位置和指标解释必须一致。

如果要测“每次创建一个新切片并追加数据”的完整成本，变量应在循环内创建：

func BenchmarkAppendFresh(b *testing.B) {
    chunk := make([]byte, 128)
    b.ReportAllocs()

    for b.Loop() {
        // 每轮都从相同容量和长度开始，分配与 append 都属于被测工作。
        dst := make([]byte, 0, 1024)
        dst = append(dst, chunk...)

        // B.Loop 会保持循环体中的赋值与调用结果存活，通常不必再写全局 sink。
        _ = dst
    }
}

如果生产代码使用对象池或长期复用缓冲区，则可以把对象放在循环外，但每轮必须恢复到同一逻辑状态：

func BenchmarkAppendReuse(b *testing.B) {
    chunk := make([]byte, 128)
    dst := make([]byte, 0, 1024)
    b.ReportAllocs()

    for b.Loop() {
        // 将长度恢复为零并保留容量，模拟生产中的缓冲区复用。
        dst = dst[:0]
        dst = append(dst, chunk...)
        _ = dst
    }
}

这里保留容量是设计目标，不是测试漏洞。真正的问题是没有说明“测的是复用”，或者重置后仍残留会改变下一轮行为的字段、索引、缓存和随机数状态。

重置动作要不要算进基准时间

如果线上每次处理请求前都会调用 Reset，通常应把它计入每次操作。如果重置只是为了给核心算法构造等价输入，而且线上输入准备发生在其他阶段，则可在循环内使用 StopTimer 和 StartTimer 排除准备时间。Go 官方的排序示例就是先暂停计时、重新填充数组，再开始计时执行排序。

func BenchmarkParsePrepared(b *testing.B) {
    buf := make([]byte, 4096)

    for b.Loop() {
        b.StopTimer()
        // 准备动作只用于恢复等价输入，不属于本基准要比较的解析成本。
        fillDeterministicInput(buf)
        b.StartTimer()

        // 每轮解析相同规模、相同结构的输入，避免状态漂移。
        parse(buf)
    }
}

不要为了降低 ns/op 就把真实请求路径中的必要动作移出计时区间。判断标准只有一个：被排除的工作，在你要回答的性能问题中是否真的发生在计时边界之外。对于很小的操作，频繁启停计时器还会延长整个测试过程，因此最好分别提供“完整路径”和“核心操作”两个命名清楚的基准。

循环外计数器并非一定错误

“修改循环外变量”不是一条绝对禁令。固定成本的计数器、自定义指标累加器，或者用于记录总字节数的变量，可以合法地跨迭代变化。关键是它的变化不能反过来改变下一轮输入或控制流。

func BenchmarkEncode(b *testing.B) {
    input := fixedInput()
    var totalBytes int64

    for b.Loop() {
        // 累加结果用于循环结束后的自定义指标，不参与下一轮编码决策。
        out := encode(input)
        totalBytes += int64(len(out))
    }

    // B.Loop 返回 false 后 b.N 才是本次测量的总迭代数。
    b.ReportMetric(float64(totalBytes)/float64(b.N), "B/op")
}

如果计数器被用来改变分支、索引、数据大小或缓存键，那么它就从“只记录结果”变成了“修改下一轮工作负载”。此外，累加类型要能承受总迭代数，不能让溢出后的行为悄悄改变控制流。

怎样确认基准语义已经稳定

不要先盯着一次运行的快慢，而要先检查结构。循环开始前的外部对象有哪些可变字段？循环体修改了什么？下一轮是否能观察到这些修改？每轮的数据长度、命中率和分配条件是否等价？确认语义后，再用多次运行和分配统计观察波动。

# 只运行指定基准，避免普通测试干扰，并记录分配指标
go test -run='^$' -bench='BenchmarkAppend(Fresh|Reuse)$' -benchmem -count=10

# 固定 CPU 维度，减少不同调度配置给比较带来的额外变量
go test -run='^$' -bench='BenchmarkAppend(Fresh|Reuse)$' -benchmem -count=10 -cpu=1

比较时应看两件事：第一，多次结果是否在可接受范围内稳定；第二，两个基准的语义差异是否和分配指标、对象生命周期一致。Reuse 更快不代表它“修复了” Fresh，它可能只是回答了另一个问题。若要比较提交前后的变化，应在同一机器、同一 Go 版本、同一 CPU 配置下保存结果，再使用统计工具做配对比较。

常见问题

B.Loop 会自动重置循环外变量吗？

不会。它管理的是迭代与计时状态，不会复制你的业务对象。切片、map、缓冲区和结构体字段都遵循普通 Go 语义。

把变量移到循环体内就一定正确吗？

不一定。如果生产代码本来复用对象，移入循环会把分配成本混入稳态指标。正确做法是先确定要回答的问题，再决定新建还是重置复用。

循环外 map 每轮写同一个键可以吗？

要谨慎。第一轮可能是插入，后续轮次变成更新，两种路径不等价。若目标是测更新，应在计时前准备好键；若目标是测插入，应让每轮从等价的空 map 或等价容量开始。

还需要全局 sink 防止编译器优化吗？

标准形式的 for b.Loop() { ... } 会保持循环体中函数调用参数、结果和被赋值变量存活，通常不需要手工全局 sink。这个保护只适用于语法上位于标准循环体内的语句，因此不要把条件改写成包装函数，也不要假设循环外代码得到相同保护。

为什么第一次和后续轮次差很多？

常见原因是缓存预热、切片扩容、map 建桶、惰性初始化或对象容量复用。先检查这些状态是否属于目标语义；若不属于，就在每轮恢复等价状态，若属于，就明确把基准命名为 warm 或 reuse。

参考资料

• testing.B.Loop 官方文档：https://pkg.go.dev/testing#B.Loop
• Go 官方博客：https://go.dev/blog/testing-b-loop
• Go 1.24 发布说明：https://go.dev/doc/go1.24
• testing 基准实现源码：https://go.dev/src/testing/benchmark.go