Go 基准怎样报告业务自定义指标

Go 基准可以用 b.ReportMetric(value, unit) 把业务指标加入结果。它报告你传入的数值，不会看到单位带有 /op 就自动除以迭代次数。若累计的是总处理量，报告每次操作的处理量时必须自己除以 b.N。

设想一次批处理接收八条记录，其中只有正数被接纳。只看 ns/op，读者不容易知道“一次操作”是单条还是整批；加上 records/op 与 accepted/op，可以把工作量解释清楚。这是一个演示口径的场景，不是已测出的性能改进案例。

补充业务口径，不需要替换默认耗时

ReportMetric 是 testing 的现有能力，这里不把它包装成最新版本发布。改动的价值是让基准结果同时具有耗时维度和业务数量维度：默认 ns/op 留着，自定义单位表达一批里究竟完成多少有效工作。

官方文档入口：https://pkg.go.dev/testing#B.ReportMetric。计时与指标实现参考：https://go.dev/src/testing/benchmark.go。本文沿用 b.N 循环，专注单位和输出，不展开新旧循环 API 的迁移。

先把“一次操作”写成可解释的定义

示例中一次 op 是一次 acceptBatch 调用，不是其中一条记录，也不是整个基准运行。累计接纳总数是 totalAccepted，迭代次数是 b.N，每操作接纳数按 float64(totalAccepted) / float64(b.N) 计算；先转浮点再除，避免整数除法截断。

与之不同，输入批大小 len(values) 本身已经是每次调用的记录数，直接报告即可，不能再除一次 b.N。这两种来源的数值可以用不同单位并列，前提是读者能从代码和说明还原分子、分母。

一个能够放入测试文件的例子

package metricdemo

import "testing"

// acceptBatch 只演示业务工作量口径，不代表真实服务吞吐。
func acceptBatch(values []int) int {
    accepted := 0
    for _, v := range values {
        if v > 0 {
            accepted++
        }
    }
    return accepted
}

var acceptedSink uint64 // 保留计算结果，避免仅为演示而丢弃结果。

func BenchmarkAcceptBatch(b *testing.B) {
    values := []int{9, -2, 0, 4, 7, -1, 3, 0}
    var totalAccepted uint64 // 每次基准函数调用独立累计。
    b.ResetTimer() // 准备数据不计入，并在报告自定义指标之前重置。

    for i := 0; i 

将代码放到一个已初始化模块的包目录，文件名例如 metric_test.go，包名与该目录约定保持一致。可用下面的命令选择这一个基准：

# 在放置上述metric_test.go的包目录执行，只选择目标基准。
go test -run='^$' -bench='^BenchmarkAcceptBatch$' -count=1

本文没有执行该基准，不提供伪造的 ns/op 或分配数字。根据固定输入推导，业务单位中 records/op 应表达8、accepted/op 应表达4；具体数字打印精度、迭代次数与耗时依运行环境和工具链而定。这两个业务常量只能说明输入和筛选口径，不能证明算法更快。

totalAccepted 定义在基准函数内部，而不是放到包级变量里持续累加。基准框架可能为校准而多次调用基准函数，跨调用混用总数会把不同次的迭代量揉在一起。示例的包级 sink 只接收最终计算值，不作为下一次测量的初始累计量。

单位不是展示标题，它也是指标标识

单位不能为空，也不能包含空白字符；例如 accepted/op 可以，而带空格的“accepted records/op”不符合要求。业务说明写在正文或注释里，不把长句硬塞进单位。

同一个单位重复调用 ReportMetric，后一次会覆盖此前的值，而不是累加或平均。因此不要在循环里每处理一个批次就报告一次，然后期待框架替你求和。先在局部变量里累计，到结束时只报告已经归一化的结果。

迁移时最容易忽略的是重置与覆盖

ResetTimer 会清除用户报告的指标，因此把报告放在准备和重置之前，后面再重置，就可能丢掉它。示例把 ResetTimer 放在循环前，将 StopTimer 放在循环后，再计算并报告；StopTimer 与 ResetTimer 不是同一回事，停止计时并不等于清空指标。

如果使用框架本来的单位，例如 allocs/op，自定义报告会覆盖对应默认指标。把 ns/op 报为0还会抑制该默认项。除非明确需要改变展示，否则业务数量使用专属名称，避免让手工数值冒充框架测量值。

迁移一个现有基准时，应先在注释里明确一次 op，再定位累计变量的生命周期，最后选择不会撞默认项的单位。只有这些定义一致，两个实现的结果才值得放在一起比较。

输出读数还要回答两个问题

accepted/op 越高就越好吗？ 不一定。它可能只是输入中符合条件的记录变多；比较性能时需要相同数据与相同接纳规则，否则工作量不同。

加上 /op 后还需要自己计算吗？ 需要。后缀是约定，ReportMetric 不替你理解业务公式。反过来，已经是每次操作的常量也不要再次归一化。

能直接把总量写成 records/op 吗？ 不应该。总量与单次量是不同单位含义；如果故意展示全次总量，应另起能表达总量的名称，并说明它会随迭代次数变化，通常不适合跨运行直接比较。

自定义指标的重点不是多显示几列，而是给每一列一个稳定、可还原的业务定义。先算对数值，再选对单位，最后让框架负责展示。