Go testing.B ReportMetric 如何记录自定义指标

Go 基准测试除了输出默认的 ns/op、分配次数，还可以把“每次操作比较了多少次”“每纳秒处理了多少项”这类结果写进同一行。testing.B.ReportMetric 的关键不是把一个累计数字直接塞进去，而是先明确指标的分母，再用不含空白的单位名上报。这样跑不同机器、不同 -benchtime 时，结果仍然有可比性。

把累计计数转换为可比较的每次操作指标

假设要观察排序过程中的比较次数，循环里得到的是整个基准阶段的累计值，而不是一次操作的成本。直接上报累计值会随着 b.N 改变，无法比较。正确做法是把计数转换成 float64(compares) / float64(b.N)，再用 compares/op 表达“每次操作”。

func BenchmarkSort(b *testing.B) {
	var compares int64
	for b.Loop() {
		values := []int{5, 4, 3, 2, 1}
		sort.Slice(values, func(i, j int) bool {
			// 累计一次比较，循环结束后再统一换算。
			compares++
			return values[i] 

单位字符串不能是空串，也不能含空白；/op 不是强制语法，但它能让读者和基准工具迅速看懂分母。若使用旧式的 for i := 0; i 也遵循同一计算逻辑。

区分按操作次数和按耗时的单位

同一个累计值可以表达两种不同问题：一次操作平均触发多少次比较，或一纳秒内完成多少次比较。前者的分母是 b.N，后者的分母是 b.Elapsed().Nanoseconds()。不要把两个单位都叫 metric，否则读者无法判断结果的尺度。

elapsedNS := b.Elapsed().Nanoseconds()
if elapsedNS > 0 {
	// 只有在计时窗口已经产生时，才计算按纳秒归一化的指标。
	b.ReportMetric(float64(compares)/float64(elapsedNS), "compares/ns")
}

ReportMetric 会把自定义值加入基准结果；如果单位正好是框架已有单位，后报的值会覆盖内置值。一般先使用自己的单位，除非你确实想重定义某个内置结果。

在并行基准的汇总点统一上报

RunParallel 会让多个 worker 同时执行，普通整数自增会产生数据竞争。把计数器换成 atomic.Int64，并把 ReportMetric 放在 RunParallel 返回之后：此时所有 worker 已完成，b.N 代表总操作数，指标只计算一次。

func BenchmarkParallel(b *testing.B) {
	var compares atomic.Int64
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			// 并行路径必须使用原子累加，避免数据竞争。
			compares.Add(1)
		}
	})
	// RunParallel 返回后再读取总数并上报，避免读取中间状态。
	b.ReportMetric(float64(compares.Load())/float64(b.N), "compares/op")
}

处理重复单位与内置指标覆盖

同一单位多次调用时，后一次值会覆盖前一次值。因此不要在循环里反复调用 ReportMetric，而应在样本收集结束后保留最终值。另一个容易忽略的边界是内置指标：如果调用 b.ReportMetric(12345, "ns/op")，它会改写框架计算的 ns/op；把 ns/op 设为 0 还可以抑制这个内置指标。除非有明确的报告格式要求，否则不要覆盖它。

发布前可以按这张清单复查：单位是否为空或含空白；累计值是否除以了正确分母；并行计数是否原子化；上报是否位于并行工作结束之后；是否意外重用了 ns/op、allocs/op 等内置名称。

相关问题

ReportMetric 的单位可以写带空格的中文吗？

不可以。单位不能为空，也不能包含空白；建议使用简短、稳定、能说明分母的 ASCII 单位，例如 items/op。

为什么自定义指标每次运行的数值会变化？

基准迭代次数、计时窗口和机器负载都会影响测量。先保证分母定义正确，再用多次运行和 benchstat 比较趋势，不要把单次结果当成固定常量。

并行基准能在 worker 内调用 ReportMetric 吗？

不建议。worker 内的数据还在变化，且会让同一单位多次覆盖；把计数汇总后在 RunParallel 返回处统一上报更可靠。