用 B.Loop 正确排除一次性初始化开销

我在给一段哈希代码补基准测试时，最容易先写出的是 for i := 0; i 。这段写法本身没有错，但只要每轮测量前还要准备输入、分配缓冲区或建立对象，初始化成本就可能和被测操作混在一起。Go 1.24 引入的 testing.B.Loop 给了更清晰的边界：把一次性准备放在第一次 b.Loop() 之前，循环体只保留真正想测的调用，循环结束后的清理也不计入结果。

先把基准测试拆成三块

一个可读的基准通常有三个区域：准备输入、执行被测操作、释放资源。下面用计算 SHA-256 作为小项目的目标，只是为了让“初始化一次、计算多次”的关系足够明显。输入构造、填充随机数据等动作属于准备区，不应该因为基准框架为了达到稳定测量时长而被反复计数。

把一次性输入放到 B.Loop 之前

核心写法是让 input := buildInput() 位于循环之前，并让 hashBlock(input) 成为循环内唯一的主要工作。B.Loop 首次调用会重置计时器，因此准备输入不会进入计时；它返回 false 后计时器停止，循环后的资源回收也不会污染结果。

package loopbench

import (
    "crypto/sha256"
    "testing"
)

func buildInput() []byte {
    // 这份输入只创建一次，避免把准备成本算进每次哈希。
    data := make([]byte, 128

这里的 _ = hashBlock(input) 不是多余写法。官方文档说明，B.Loop 循环体内的函数调用参数、返回值和赋值变量会被保持存活，降低编译器把无副作用调用完全优化掉的风险。它解决的是“基准循环被优化”的边界，不代表所有外部副作用都能自动变成可靠测量；如果被测函数本身依赖时钟、网络或共享状态，仍要单独设计隔离方案。

不要把 b.N、清理和并行模型混在一起

旧式 b.N 基准依赖测试框架多次调用基准函数，再调整 N 以获得足够长的测量时间，所以昂贵准备可能随调用重复发生。迁移到 B.Loop 时，应删除显式的 b.N 循环，而不是在外面再套一层。两种写法也不要放在同一个基准函数里，否则读者很难判断计时边界。

用 go test 检查测量对象

把代码放进以 _test.go 结尾的文件后，可以用下面的命令只跑目标基准，并同时输出分配统计：

# 只运行目标基准，并显示每次操作的分配信息
go test -run '^$' -bench '^BenchmarkHashPreparedInput$' -benchmem ./...

如果项目仍需支持 Go 1.23 或更早工具链，不能直接调用 B.Loop；可以保留旧式 b.N 写法，并用 b.ResetTimer() 把准备阶段排除在计时外。升级到 Go 1.24 后再迁移时，优先检查三点：循环条件是否精确写成 b.Loop()、循环体是否真的只包含被测操作、旧的 b.N 是否已经移除。

常见问题

B.Loop 能不能和 b.N 一起使用？

不建议。一个基准选择一种迭代模型即可；B.Loop 已经负责循环次数和计时边界，混用会让测量语义变得不清楚。

准备阶段很慢，为什么仍然要放在循环前？

因为标题关注的是被测操作的开销。若准备阶段本来就是业务目标的一部分，应把它写成另一个独立基准，而不是把两种成本悄悄相加。

B.Loop 适合并行基准吗？

并行场景继续使用 b.RunParallel 与 pb.Next()。B.Loop 的优势是顺序基准的迭代和计时管理，不会替代并行基准的工作分配模型。

把一次性初始化、循环体和清理拆开后，B.Loop 的价值不只是少写一个计数变量，而是让基准结构直接表达“测什么”。先确认工具链版本，再让循环体只承载目标调用，最后用 go test -benchmem 查看结果，迁移后的数据才有可解释性。