Go 1.26 B.Loop 怎么迁移基准测试：内联变化与优化掉代码的检查

把旧的 for range b.N 改成 for b.Loop()，真正需要复查的是“测了什么”，不是循环语法本身。Go 1.26 保留了 B.Loop 对循环体内函数调用参数、返回值和赋值变量的保活语义，同时不再用 B.Loop 阻止循环体内联；因此迁移后应同时看计时边界、编译诊断和重复测量。

最稳妥的迁移结果是：准备数据在循环外，目标调用完整地位于 B.Loop 花括号内，循环只测同一种操作，再用 -benchmem 和多次运行确认比较口径没有变。

先把 B.N 基准拆成可比的 B.Loop 结构

旧基准常见写法是：

func BenchmarkParse(b *testing.B) {
    input := []byte("region=cn&limit=20")
    for range b.N {
        parse(input)
    }
}

迁移时只保留一个循环，并把不属于被测操作的输入准备放在前面：

func BenchmarkParse(b *testing.B) {
    input := []byte("region=cn&limit=20")
    for b.Loop() {
        parse(input)
    }
}

这里的边界很具体：不要在 B.Loop 里重新拼接输入，也不要把旧的 b.N 循环留下来。循环外清理也不属于被测操作。否则新旧结果不再是同一个负载的比较。

把真正要测的调用放进循环体

B.Loop 的关键不是“替你调用函数”，而是让循环体里的输入参数、函数调用结果和赋值变量保持存活。比如 parse(input) 即使没有把返回值写入全局 sink，也不会因为没有明显副作用就整段消失。

这个保护有一个容易忽略的语法边界：循环条件必须写成 b.Loop()，目标语句必须在花括号内部。把调用包到循环外的 helper，或把逻辑挪到条件表达式，都不能按同样方式理解。函数本身仍应代表真实业务动作，而不是为了迎合基准而新增一层空操作。

用 Go 1.26 检查内联与基准边界

Go 1.26 的变化是 B.Loop 不再阻止循环体内联。这个调整避免为了基准框架牺牲普通编译优化，但不等于“编译器可以删掉整个测试”：官方文档仍说明，循环体内的参数、结果和赋值变量会保持存活。

遇到迁移前后数字变化，先把命令固定下来：

go test -run '^$' -bench BenchmarkParse -benchmem -count=5
go test -run '^$' -bench BenchmarkParse -gcflags=-m=2

第一条看重复测量和分配口径，第二条只是辅助观察内联与逃逸诊断。不要把编译器的一行提示直接当成性能结论，更不要用一次快跑结果证明迁移成功。真正需要比对的是同一输入、同一目标函数和同一计时区域。

处理计时、分配和并行基准的误差

B.Loop 首次进入循环时会启动计时，返回 false 时停止计时，所以循环前后的固定准备和清理通常不需要手写 ResetTimer。但如果每轮必须生成随机输入、刷新缓冲区或做其他准备，就要在循环中显式停表，再启动计时；否则测到的是“准备加目标操作”。

for b.Loop() {
    b.StopTimer()
    refill(input)
    b.StartTimer()
    parse(input)
}

分配则用 -benchmem 复查。并行场景仍由 b.RunParallel 描述，不能因为顺序基准迁成 B.Loop，就把并发模型也一起改掉。生产代码更关心尾延迟时，还应把 benchmark 数字和真实请求画像分开看。

常见问题：为什么 B.Loop 结果仍然不可信

B.Loop 能保证业务函数一定被正确执行吗？

不能。它解决的是基准循环里的计时与编译器优化边界，输入校验、返回值语义和业务断言仍要由普通测试负责。

循环里调用 StopTimer 会不会破坏 B.Loop？

不会，但它改变了测量对象。只有 StartTimer 与 StopTimer 之间的代码进入统计，前提是每轮控制一致。

迁移后还可以用 b.N 吗？

可以在循环结束后用它计算派生指标，因为此时 b.N 是实际迭代总数；不要再用 b.N 启动第二个循环。

迁移完成后，先看循环结构，再看调用位置，最后才看数字。只要三者对应同一个被测对象，B.Loop 才真正发挥了简化基准和减少误判的价值。