Benchmark函数内不可直接用循环跑多组数据，因为go基准测试框架通过b.N动态调整执行次数，自行循环会使b.N失效、结果失真；正确做法是使用b.Run注册子基准测试，每个子项独立计时且共享setup/teardown。
为什么 Benchmark 函数里不能直接用循环跑多组数据
Go 的基准测试框架在运行时会反复调用同一个 Benchmark 函数，并根据耗时动态调整执行次数（b.N）。如果你在函数体内自己写 for 循环遍历测试用例，b.N 就失去了意义——它只会被外层框架当成“单次操作”，导致结果严重失真，比如显示 1ns/op，实际掩盖了真实开销。
正确做法是让每组输入成为独立的 Benchmark 函数，或用子基准测试（sub-benchmark）显式注册。后者更贴近表格驱动的本意。
- 子基准测试通过
b.Run(name, fn)注册，框架会为每个name单独计时、单独跑 warmup 和采样 - 所有子测试共享父
Benchmark的 setup/teardown 逻辑，避免重复初始化开销干扰对比 - 名字必须是合法标识符（不能含空格、斜杠等），否则
go test -bench会跳过该子项
b.Run() 里怎么组织测试数据才不踩坑
表格数据通常定义为切片，但容易犯两个错：一是把 setup 放进循环体导致重复执行，二是没隔离各子测试的变量作用域，造成意外复用。
推荐结构是先声明数据表，再在 b.Run 回调里做最小必要计算：
立即学习“go语言免费学习笔记（深入）”；
func BenchmarkParseInt(b *testing.B) {
tests := []struct{
name string
input string
base int
}{
{"base10", "12345", 10},
{"base16", "ff", 16},
{"base2", "10101", 2},
}
for _, tt := range tests {
tt := tt // 必须显式捕获，否则闭包会共用最后一个 tt
b.Run(tt.name, func(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = strconv.ParseInt(tt.input, tt.base, 64)
}
})
}
}
- 循环内
tt := tt是关键，否则所有子测试会读到同一份内存地址（Go for range 变量复用） - 耗时操作（如
ParseInt）必须放在b.N循环内，不能提前提取结果再循环返回——那测的是内存访问速度 - 如果 setup 成本高（如构建大 map、打开文件），应提到
b.Run外部，用局部变量传入，避免每次子测试都重做
如何让 go test -bench 只跑特定表格项
子基准测试的名字会拼接到主函数名后，形成完整路径，比如 BenchmarkParseInt/base10。这决定了过滤方式。
- 匹配单个：
go test -bench=BenchmarkParseInt/base10 - 匹配多个（正则）：
go test -bench="BenchmarkParseInt/(base10|base16)" - 排除某项：
go test -bench="BenchmarkParseInt/*" -benchmem | grep -v base2（需配合 shell） - 注意：名字中不能有空格或点号，否则
-bench解析失败，框架静默跳过
性能差异大的表格项混在一起跑，结果还靠谱吗
靠谱，但要看清输出。Go 基准测试对每个子项单独统计 ns/op 和内存分配，不会取平均值。你看到的是并列结果：
BenchmarkParseInt/base10-8 1000000000 0.32 ns/op BenchmarkParseInt/base16-8 1000000000 0.41 ns/op BenchmarkParseInt/base2-8 1000000000 0.57 ns/op
真正要小心的是隐性干扰：
- CPU 频率调节（如 Intel SpeedStep）可能在长测试中途降频，建议加
GOMAXPROCS=1减少调度抖动 - 某些输入触发了底层优化分支（如小整数缓存），而其他没有，这时差异反映的是算法路径而非纯“输入长度”影响
- 如果某项因 panic 或超时提前退出，整个
go test进程会中断，需用defer/recover包裹关键逻辑并记录日志
表格驱动本身不解决性能归因问题，它只是把可比项对齐展示。真要定位瓶颈，得结合 go tool pprof 看各子项的调用栈分布。
