Go 基准测试怎么用 ReportMetric 输出自定义吞吐指标

当标准基准结果只有 ns/op 和 allocs/op，但读者还想知道“每次处理了多少条记录”或“每秒完成了多少次比较”时，可以调用 testing.B.ReportMetric 增加自定义指标。最小写法是先累计工作量，再在基准循环结束后除以 b.N，用以 /op 结尾的单位上报：

func BenchmarkParse(b *testing.B) {
    input := []byte("name=golang&level=1")
    var fields int64

    // b.Loop 只包住需要计时的解析工作，准备输入不计入基准结果。
    for b.Loop() {
        fields += int64(bytes.Count(input, []byte("&")) + 1)
    }

    // 总字段数除以迭代次数，得到每次操作处理的字段数。
    b.ReportMetric(float64(fields)/float64(b.N), "fields/op")
}

关键点只有三个：数值要和单位的含义匹配，单位不能含空白；按每次迭代统计时除以 b.N，按耗时统计时才使用 b.Elapsed()。同一个单位重复上报时，后一次会覆盖前一次。

先把“吞吐”定义成可计算的量

基准测试中的吞吐不是一个固定字段，而是“完成的工作量 ÷ 基准运行的某个基准”。例如一次迭代处理一条消息，可以上报 messages/op；一次迭代扫描若干字节，可以上报 bytes/op；如果关心单位时间内完成的工作量，则可以用 items/ns，或自行换算为 items/s。

ReportMetric 接收一个 float64 和一个字符串单位。它不会替你判断“这个数是不是吞吐”，也不会自动把总计数换成每次迭代的数值。因此，先在纸上写出分子、分母和单位，再写代码，能避免报告中的小数看起来合理但含义错误。

按每次迭代输出 /op 指标

如果指标描述“平均每次基准迭代完成多少工作”，单位通常以 /op 结尾，分母就是 b.N。下面的例子统计每次排序调用触发了多少次比较：

func BenchmarkSortComparisons(b *testing.B) {
    input := []int{5, 4, 3, 2, 1}
    var comparisons int64

    // 每轮复制输入，避免排序后的切片改变下一轮的工作量。
    for b.Loop() {
        data := append([]int(nil), input...)
        sort.Slice(data, func(i, j int) bool {
            comparisons++
            return data[i] 

这里的 comparisons 是整个基准过程的累计量；如果直接把它上报为 comparisons/op，运行次数越多，数值反而越大，指标就不再是“每次操作”的平均值。使用 b.Loop() 时，循环结束后 b.N 仍表示实际运行的迭代总数。

按耗时输出 /ns 指标

当问题是“单位时间完成多少工作”，可以用 b.Elapsed() 得到基准计时区间，再把累计工作量除以纳秒数。官方示例也采用了 work/ns 这一类单位：

func BenchmarkEncodeRate(b *testing.B) {
    payload := []byte("a small payload")
    var encoded int64

    // 只统计计时区间内实际完成的编码工作量。
    for b.Loop() {
        encoded += int64(base64.StdEncoding.EncodedLen(len(payload)))
        _ = base64.StdEncoding.EncodeToString(payload)
    }

    // 用耗时作分母，表示每纳秒产生多少编码字节。
    b.ReportMetric(float64(encoded)/float64(b.Elapsed().Nanoseconds()), "encoded-bytes/ns")
}

/op 和 /ns 不是同一个指标的两种写法：前者反映一次迭代的平均工作量，后者反映时间维度上的工作速率。如果要给人阅读，可以在代码里把每纳秒结果换算成每秒，但要同步把单位改成 /s，不要只改单位字符串。

单位名和重复上报最容易造成误读

单位字符串不能为空，也不能包含空格或制表符。建议使用短、稳定、能表达分母的名字，例如 rows/op、bytes/op、comparisons/ns。不要把一串自然语言塞进单位，也不要用同一个单位同时表示“总量”和“每次迭代量”。

同一个单位再次调用 ReportMetric 时，后一次数值会覆盖前一次，而不是追加两项。这个行为适合在计算完成后统一上报，但不适合把多个阶段都写成同名指标。若确实要区分阶段，应使用不同单位名，例如 parse-items/op 与 encode-items/op。

框架自带的指标也可以被覆盖。比如把 ns/op 上报为 0 会抑制默认的 ns/op，而用 ReportMetric 写入同名内置指标会替换默认值。除非有明确的报告格式需求，否则不建议覆盖标准指标；保留原始 ns/op 更方便和其他基准比较。

ResetTimer 会清掉之前的自定义指标

如果在基准函数中途调用 b.ResetTimer()，计时器和分配统计会被清零，同时之前由用户上报的指标也会被删除。常见的安全顺序是：先完成不计时的准备工作，再调用 ResetTimer，最后只在计时区间结束后计算并上报指标。

func BenchmarkLookup(b *testing.B) {
    table := buildTable()
    key := "target"

    // 清除建表阶段的计时与旧指标，下面才是正式测量区间。
    b.ResetTimer()
    var hits int64
    for b.Loop() {
        if _, ok := table[key]; ok {
            hits++
        }
    }

    // 上报前不要再次 ResetTimer，否则该指标会被清除。
    b.ReportMetric(float64(hits)/float64(b.N), "hits/op")
}

运行结果怎么读

把代码放在以 _test.go 结尾的文件中，用 go test -bench=Benchmark -benchmem 运行。输出中的自定义指标会和标准指标出现在同一行；它们描述的是同一次基准运行，不会自动变成外部监控数据。

写文章或提交代码前，可以用下面这张表做快速复盘：

常见问题

ReportMetric 能不能在每轮循环里调用？可以调用，但通常没有必要。按基准结果汇总后在循环外调用一次，更容易保证分子、分母和最终单位一致。

为什么自定义指标越跑数值越大？通常是把累计总量直接标成了 /op，却没有除以 b.N；也可能把“每秒”写成了 /ns。先检查单位和分母是否一致。

ReportMetric 能替代 SetBytes 吗？两者用途不同。SetBytes 会让框架计算标准的字节吞吐展示；ReportMetric 用来表达业务或算法特有的工作量。需要自定义名称时使用后者。

自定义指标会不会自动上传到监控系统？不会。它只是写入本次 Go benchmark 的结果文本；外部采集、对比和趋势分析需要由其他工具单独处理。

记住“先定义分子，再选择分母，最后命名单位”：按迭代平均就除以 b.N，按时间速率就除以 b.Elapsed()，同单位只保留最后一次结果。这样 ReportMetric 输出的吞吐指标才不会看起来精确，却在语义上失真。