Go 测试怎样只运行指定的基准子测试

当一个 Go 基准函数里又拆了 JSON、CSV、不同数据规模等子基准时，直接运行整组基准会让定位一次改动变得很慢。更稳妥的做法是给子基准建立稳定名称，再用 -bench 的正则按层级筛选。

官方资料：https://pkg.go.dev/cmd/go#hdr-Testing_flags

核心写法是 go test -run='^$' -bench='^BenchmarkEncode$/JSON$' -count=1 ./...：第一层锁定父基准，第二层锁定名为 JSON 的子基准。父基准可能会先以 b.N=1 进行探测，这是为了发现匹配的子基准，不代表父基准被完整测量了一遍。

先把基准名称设计成可筛选的层级

testing.B.Run 会把当前基准名和传入的子名称用斜杠连接起来。下面的结构会形成稳定名称树，后续命令可以直接针对某一层筛选。

func BenchmarkEncode(b *testing.B) {
    cases := []struct {
        name string
        data []byte
    }{
        {name: "JSON/Small", data: []byte(`{"id":1}`)},
        {name: "JSON/Large", data: bytes.Repeat([]byte(`{"id":1}`), 64)},
        {name: "CSV/Small", data: []byte("id,name\n1,go\n")},
    }

    for _, tc := range cases {
        tc := tc // 中文注释：复制循环变量，避免闭包使用错误的用例值。
        b.Run(tc.name, func(b *testing.B) {
            for i := 0; i 

这里的完整名称大致是 BenchmarkEncode/JSON/Small、BenchmarkEncode/JSON/Large 和 BenchmarkEncode/CSV/Small。名称中的斜杠既是层级分隔符，也是 -bench 过滤式的边界。

用 -bench 逐层筛选目标子基准

如果只想运行 BenchmarkEncode 下的 JSON 子基准，可以把正则拆成父层和子层：

# 中文注释：^ 和 $ 让父层、子层分别精确落在目标名称上。
go test -run='^$' -bench='^BenchmarkEncode$/JSON$' -count=1 ./...

-run='^$' 用来避免普通测试占用本轮输出；它不是筛选基准的核心参数。-bench 里的斜杠会把表达式分层匹配：先找到父层 BenchmarkEncode，再在它的子名称中寻找 JSON。如果 JSON 下面还有 Small 和 Large，父层会被调用一次来发现子基准，最终会进入对应的子项。

只想比较 JSON 下的 Large，可以继续写到末级：

# 中文注释：末级加 $，避免把 LargeExtra 等相似名称一起选中。
go test -run='^$' -bench='^BenchmarkEncode$/JSON$/Large$' -count=1 ./...

命令里的引号建议保留。这样可以避免 shell 对正则中的特殊字符进行额外解释，也让命令在脚本和终端里更容易复制。

正则边界决定你到底跑了多少内容

筛选不只是“有没有匹配”，还要确认匹配层级是否符合预期。下面几个写法的意图不同：

尤其要注意 ^ 和 $。没有开始、结束锚点时，名称里只要出现目标片段就可能命中；名称中还包含斜杠时，Go 会按未转义的斜杠切分匹配层级。因此，团队约定的基准命名最好只使用稳定、简短、可读的层级。

把筛选命令写成可审计的运行手册

在团队里，最容易出错的不是不会写 -bench，而是每个人临时写出一套不同的筛选方式。可以把目标、命令和命名约束放在同一份脚本说明中：

# 中文注释：只运行 Encode/JSON/Large，普通测试保持关闭。
set -eu
pattern='^BenchmarkEncode$/JSON$/Large$'
go test -run='^$' -bench="$pattern" -count=1 ./...

# 中文注释：修改 pattern 时同步更新基准名称，避免脚本悄悄退化成全量运行。
echo "benchmark pattern: $pattern"

如果命令输出为空，先区分两种情况：一是包路径没有找到对应基准，二是正则层级和实际名称不一致。可以先用 -bench='.' 看名称，再收紧到父层和末级；不要一开始就把一个很长的正则塞进持续集成配置。

发布到 CI 前还应固定 -count=1 或明确重复次数，记录筛选模式，并在代码评审中把名称改动和运行脚本一起看。这样能降低“基准重命名后脚本仍然成功但实际没有测到目标”的风险。

常见边界和结论

• 基准子测试的完整名称来自父名称与 b.Run 子名称的层级组合，先设计命名再设计筛选式。
• -bench='.' 是全量入口；精确任务优先使用 ^、$ 和斜杠分层。
• 父基准出现一次探测调用是发现子基准的机制，不应当直接当成完整性能结果。
• 脚本里保留引号、固定包路径和运行次数，并在命名变更时同步更新筛选模式。

相关问题

为什么 -bench 不写参数时看不到基准结果？

默认情况下不运行基准，需要使用 -bench='.' 或更具体的正则。

为什么筛选到子基准时父基准也出现了？

父基准需要先执行发现子基准的过程；这次探测通常不是父基准的完整计时。

怎样确认正则没有跑宽？

先用更宽的模式列出名称，再逐层加入父名称、子名称和末尾锚点；同时把最终模式记录在脚本输出里。