Go testing.B怎样让基准测试报告自定义指标为什么结果为空或不符合预期

Go 基准测试要在报告中增加自定义指标，关键是把 b.ReportMetric 放在测量逻辑完成之后，并让数值与单位保持同一语义：按每次迭代统计就除以 b.N，按时间统计就除以 b.Elapsed()。如果指标为空，优先检查它是否在 b.ResetTimer() 之前报告；如果数值特别大，优先检查是否把总次数直接当成了每次操作的指标。

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

先确认指标报告的三个条件

testing.B.ReportMetric(n, unit) 做的事情很明确：把一个数值和一个单位加入基准报告。它不会替你判断这个数值是“总量”还是“每次操作”，也不会自动把任意单位换算成每秒或每次迭代。

排障时可以先把问题拆成三个条件：

官方文档还说明，用户指标可以覆盖同名的内置指标；例如报告单位为 ns/op 的值会替换默认的 ns/op，报告 ns/op 为0则可以抑制这个内置指标。这个能力适合非常明确的场景，不建议把它当作隐藏默认结果的通用手段。

把自定义指标放在测量结束处

下面的例子统计排序过程中比较函数被调用的次数。b.Loop() 负责控制测量循环，循环结束后 b.N 是实际迭代次数，b.Elapsed() 是本次基准的测量耗时。只有在这些数据都确定后，才能计算每次迭代和每纳秒的指标。

package main

import (
    "cmp"
    "slices"
    "testing"
)

func BenchmarkSortMetrics(b *testing.B) {
    var compares int64

    for b.Loop() {
        values := []int{5, 4, 3, 2, 1}
        slices.SortFunc(values, func(left, right int) int {
            // 在被测循环内累计业务指标，不把总次数误当成每次迭代值。
            compares++
            return cmp.Compare(left, right)
        })
    }

    // /op 表示每次迭代，必须用总次数除以实际迭代数。
    b.ReportMetric(float64(compares)/float64(b.N), "compares/op")

    // /ns 表示每纳秒，先取得已测量的总耗时再换算。
    elapsedNS := b.Elapsed().Nanoseconds()
    if elapsedNS > 0 {
        b.ReportMetric(float64(compares)/float64(elapsedNS), "compares/ns")
    }
}

这里的 compares 是总量，而 compares/op 是平均量，两者不能混用。若把总量直接报告成 compares/op，随着测试框架增加迭代次数，数值就会跟着变大，看起来像算法变慢，实际上只是统计口径错了。

为什么指标会为空、被覆盖或突然消失

遇到“代码执行了但报告没有自定义指标”，先按调用顺序看，而不是马上修改数值。下面几种情况最常见：

• 先报告、后重置：b.ResetTimer() 不仅重置计时和内存分配计数，也会删除用户报告的指标。需要重置时，把它放在准备阶段，最后再调用 ReportMetric。
• 同一单位多次报告：同一 unit 的后一次调用会覆盖前一次。若要保留两个口径，应使用不同单位名，例如 items/op 和 items/ns。
• 单位带空白：空字符串或包含空格、换行、制表符的单位会触发 panic。单位应是紧凑、可读、没有空白的标签。
• 在循环内反复报告：这样通常只留下最后一次值，还会把报告动作混进被测逻辑。累计数据后在循环外报告更容易解释。
• 把计时外的数据当结果：使用 b.StopTimer 或 b.ResetTimer 调整边界后，要确认计数的生命周期仍然覆盖了真正的被测区间。

一个简单的恢复动作是：保留一次 ReportMetric，使用一个固定且无空白的单位，放在单基准函数的最后；然后再逐步加入多个指标。这样能把“调用没有生效”和“单位被覆盖”区分开。

让 b.N、b.Elapsed 和单位保持同一口径

自定义指标最容易出错的地方，是分子和单位不匹配。可以按下面的规则判断：

单位后缀不是强制的语法，但它是读者理解数值的关键信息。官方示例把按迭代计算的指标标为 /op，把按时间计算的指标标为 /ns；沿用这个约定可以避免报告看起来“有值却不知道怎么解释”。

处理并行基准的计数

RunParallel 会把 b.N 次迭代分发到多个 goroutine。普通整数在多个 worker 中直接自增会产生数据竞争，计数结果也不可靠。更稳妥的边界是：worker 只做被测操作和原子累加，RunParallel 返回后由主基准统一读取并报告。

package main

import (
    "slices"
    "sync/atomic"
    "testing"
)

func BenchmarkParallelSortMetric(b *testing.B) {
    var compares atomic.Int64

    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            values := []int{5, 4, 3, 2, 1}
            slices.SortFunc(values, func(left, right int) int {
                // 多个worker会同时执行，使用原子计数避免竞争写入。
                compares.Add(1)
                if left  right {
                    return 1
                }
                return 0
            })
        }
    })

    // 等所有worker结束后再读取总数并生成每次迭代指标。
    total := compares.Load()
    b.ReportMetric(float64(total)/float64(b.N), "compares/op")
}

并行示例中不应在 worker 内调用 ReportMetric，也不应依赖某个 worker 看到的局部计数代表整个基准。主基准在 RunParallel 返回后才拥有完整汇总边界。若要按时间计算速率，同样在返回后使用 b.Elapsed()，不要把各 goroutine 的局部耗时相加后冒充整体墙钟时间。

用最小命令复查报告边界

文章示例使用 Benchmark 前缀的函数，运行时可以只筛选它，减少其它基准对判断的干扰：

# 只运行目标基准，并显示内存相关内置指标。
go test -run '^$' -bench '^BenchmarkSortMetrics$' -benchmem -count=1

# 并行示例使用指定的CPU并发档位，便于比较不同设置下的报告。
go test -run '^$' -bench '^BenchmarkParallelSortMetric$' -cpu=1,2 -count=1

-run '^$' 用于跳过普通测试，-bench 负责筛选基准，-count=1 避免把缓存的多次结果误认为当前单次输出。这里的命令只用于复查报告格式；真实性能结论仍应结合多次运行和合适的统计工具，不能从一行演示输出推断生产收益。

如果命令只看到默认的 ns/op，先确认函数是否真的调用了 ReportMetric；如果看到自定义单位但数值随 -benchtime 明显放大，检查是否漏除了 b.N；如果并行输出不稳定，检查是否存在普通共享计数或过早读取。

正式使用前的排障清单

• 基准函数名称是否以 Benchmark 开头，并被 -bench 选中？
• 自定义指标是否在测量结束后只报告一次？
• 单位是否非空、无空白，并能表达总量、每次或每时间的含义？
• 按迭代统计时是否除以 b.N，按时间统计时是否除以 b.Elapsed()？
• 是否在最后一次 ResetTimer 后才报告指标？
• 并行场景是否使用安全的计数方式，并在 RunParallel 返回后汇总？

把这些问题按顺序排一遍，通常能区分三类故障：指标根本没被选中的命令问题、指标被清除或覆盖的调用顺序问题，以及分子和单位不一致的统计口径问题。

常见问题

ReportMetric 的单位可以写中文吗？

技术上关键约束是单位不能空、不能包含空白字符。为了方便命令行结果阅读和后续统计，建议使用简短、稳定的 ASCII 单位名，例如 rows/op、bytes/op，不要让同一个含义在不同文章或项目中随意换名。

为什么报告了自定义 ns/op 后默认 ns/op 不见了？

ReportMetric 对同名内置指标具有覆盖语义。报告 ns/op 会替换默认值；如果只是想增加一项指标，应换一个不同单位，而不是复用内置单位名。

可以在 b.Loop 循环里面直接调用 ReportMetric 吗？

不建议。重复调用同一单位只保留最后的值，且报告动作混入被测区间会让统计口径更难解释。更清晰的做法是循环里累加原始数据，循环结束后统一换算并报告。

自定义指标本身并不复杂，真正要守住的是三个边界：数据在什么时候开始计量，单位到底代表什么，以及报告动作在什么时候最终落盘。把 ReportMetric 放在最后、让 b.N 与 b.Elapsed() 对应正确，再对并行计数使用安全汇总，基准报告就不容易出现“有调用却没结果”的情况。