Go testing.B.Loop 怎样防止无副作用调用被编译器优化

写 Go 基准测试时，最容易误判的不是计时器，而是“循环里到底有没有留下要测的工作”。如果一个函数只计算结果、没有副作用，并且结果也没有被使用，编译器有机会把这段工作消掉。Go 1.24 引入的 testing.B.Loop 专门改善了这类基准循环：只要使用它规定的精确循环形式，循环体内函数调用的参数、返回值和局部变量会保持可观察，避免测到一个被优化空的循环。

关键写法是 for b.Loop() { ... }，而不是把它包进另一个条件函数。下面按“保护测量对象—识别风险路径—加入控制措施”的顺序说明。

先区分计时边界和优化边界

b.Loop() 解决的是基准迭代和计时边界：第一次调用前的准备通常不计入测量，循环结束后的清理也不计入测量。但“计时范围正确”不等于“循环体一定有有效工作”。如果工作结果在循环体内完全不可观察，普通循环可能被编译器判断为没有必要执行。

Go 官方文档对 B.Loop 有一个重要限定：循环条件必须按语法写成 b.Loop()。在这个循环体内，编译器会保留函数调用涉及的参数和结果，避免把纯计算直接优化掉。也就是说，下面的结构才是保护测量对象的最小边界：

func BenchmarkSum(b *testing.B) {
    // 准备输入数据；这部分不属于循环体的测量对象。
    data := []int{3, 5, 8, 13, 21}

    // 必须直接使用 b.Loop()，让 testing 和编译器识别基准循环。
    for b.Loop() {
        sum(data) // 中文说明：即使返回值未接到外部变量，循环体内的调用仍被保活。
    }
}

func sum(values []int) int {
    total := 0
    for _, value := range values {
        total += value // 中文说明：把每个元素累加成待测计算结果。
    }
    return total
}

为什么不能随意改写循环条件

B.Loop 的编译器支持依赖一个清晰的语法形状。下面几种写法虽然看起来都像“循环调用 Loop”，但表达的边界不同：

// 推荐：条件就是 b.Loop()，循环体获得官方定义的保活语义。
for b.Loop() {
    parseHeader(buf) // 中文说明：把要测的解析调用放在循环体内部。
}

// 不推荐：先把结果存到普通布尔变量，失去 b.Loop() 作为条件的明确形状。
for running := b.Loop(); running; running = b.Loop() {
    parseHeader(buf) // 中文说明：不要用额外控制层包住基准循环。
}

// 也不推荐：把 b.Loop() 放进自定义 helper，语义不再是精确的循环条件。
for benchmarkContinue(b) {
    parseHeader(buf) // 中文说明：自定义条件不能替代官方要求的直接写法。
}

因此，排查“基准结果异常小”时，先看循环条件是否仍然是字面上的 for b.Loop()，再看待测调用是否真的位于大括号内。不要为了复用控制逻辑，把 Loop 改造成另一个函数的返回值。

把结果接入可观察出口，兼容更复杂的测量逻辑

在标准 b.Loop 循环中，编译器会为循环体里的调用和结果提供保活处理。不过在真实项目里，结果还可能需要被统计、上报或用于自定义指标。此时把结果接入一个明确的出口更容易读懂，也能避免后续重构把计算移到循环外。

var benchmarkSink int

func BenchmarkDecode(b *testing.B) {
    payload := []byte("name=golang;version=1")

    for b.Loop() {
        value := decode(payload) // 中文说明：只把解码调用放进被测循环。
        benchmarkSink = len(value) // 中文说明：保留一个可观察结果，避免后续改写丢掉计算。
    }
}

func decode(payload []byte) string {
    return string(payload) // 中文说明：示例只表达数据转换关系，不代表线上解码性能。
}

如果要报告自定义指标，可以在循环外统一调用 b.ReportMetric；不要在每次迭代里频繁输出日志，因为日志本身会改变测量对象。对于旧式 for i := 0; i 循环，则仍应主动让结果进入变量、返回值或包级 sink，不能把旧循环当成 B.Loop 的等价替代。

发布前用四项清单检查基准是否可信

还要注意，B.Loop 不是并行基准 API，也不会替你决定循环内部的随机数据准备、计时暂停或资源清理方式。需要把每次迭代的准备动作纳入或排除计时时，应根据测量目标明确管理计时器，而不是通过改写循环条件解决。

常见问题

返回值没有赋给变量，是否一定会被优化掉？

在精确的 for b.Loop() 循环体内，Go 官方文档说明编译器会保持函数调用的参数、结果和相关变量，避免这类调用被完全消除。真正需要警惕的是把调用移出循环、改变循环条件，或退回旧式 b.N 循环后仍假定有同样的保活语义。

可以在同一个基准函数里同时使用 b.N 和 b.Loop 吗？

不建议也不应这样设计。一个基准函数应选择一种循环模型；混用会让迭代次数、计时边界和读者对测量对象的理解都变得不清晰。

为了防止优化，是否应该每次循环都打印结果？

不应该。打印会引入 I/O 成本，通常比被测计算更重。优先使用 B.Loop 自带的保活语义，或在循环中维护轻量结果、在循环外报告指标。

总结

避免 Go 基准循环测到“空工作”的核心不是盲目增加输出，而是守住两个边界：使用字面上的 for b.Loop()，让编译器识别官方保活语义；把真正要比较的调用放在循环体内，并在复杂场景保留清晰的结果出口。这样既能减少无副作用调用被优化带来的误判，也能让基准代码在后续维护中保持可读和可解释。