标准 Benchmark 函数不适合多组输入对比，因 testing.B 默认仅支持单次运行；需用 b.Run 实现表驱动基准测试，为每组参数生成独立性能指标，并注意正确调用 b.ResetTimer()、b.ReportAllocs() 等。
为什么标准 Benchmark 函数不适合多组输入对比
Go 的 testing.B 默认只允许单次运行一个基准函数，比如 BenchmarkFoo。如果你要对比不同参数组合（如不同字符串长度、不同 map 大小）下的性能，硬编码多个 Benchmark 函数会导致重复逻辑、难以维护，且无法共享 setup/teardown 代码。表驱动测试在单元测试中常见，但基准测试同样适用——关键是让 Run 方法嵌套进 Benchmark 函数里。
用 b.Run 驱动多个子基准测试
testing.B 提供了 Run 方法，支持动态命名和独立计时，这才是表驱动基准测试的核心。它会为每个子项生成独立的 ns/op、B/op 和 allocs/op，还能避免外层循环干扰内层计时逻辑。
常见错误是把数据循环写在 b.ResetTimer() 外面，导致 setup 时间被计入；或者忘记调用 b.ReportAllocs() 导致内存分配统计缺失。
- 子基准名必须是合法标识符（不能含空格或斜杠），建议用
fmt.Sprintf构造，例如"Len100" - 每个子项内部必须调用
b.ResetTimer()（如果需要重置）和b.StopTimer()（如果含非待测开销） - 若需统计内存分配，应在顶层
Benchmark函数开头调用b.ReportAllocs() - 不要在子项中调用
b.N循环之外的耗时操作（如time.Sleep），否则结果失真
func BenchmarkStringConcat(b *testing.B) {
b.ReportAllocs()
cases := []struct {
name string
n int
}{
{"Len10", 10},
{"Len100", 100},
{"Len1000", 1000},
}
for _, c := range cases {
b.Run(c.name, func(b *testing.B) {
s := make([]string, c.n)
for i := range s {
s[i] = "x"
}
b.ResetTimer()
for i := 0; i < b.N; i++ {
_ = strings.Join(s, "")
}
})
}
}
如何避免 b.N 被外层逻辑污染
b.N 是 Go 基准框架自动调整的迭代次数，目标是让总耗时接近 1 秒。如果在 b.Run 子函数里误把初始化放到了 b.N 循环内（比如反复创建大 slice），就会严重拖慢速度，导致 b.N 被压到极低值，最终 ns/op 失真。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
正确做法是：所有预处理（如构建输入数据）放在 b.ResetTimer() 之前，或用 b.StopTimer() / b.StartTimer() 显式控制计时区间。
- 错误示例：
for i := 0; i —— 每次都分配 1MB，计时包含分配开销 - 正确示例：
data := make([]int, 1e6); b.ResetTimer(); for i := 0; i - 更安全的写法：
b.StopTimer(); data := make([]int, 1e6); b.StartTimer()，尤其适合 setup 成本高且不稳定的场景
运行与解读输出的关键细节
执行 go test -bench=. -benchmem 后，你会看到类似：
BenchmarkStringConcat/Len10-8 10000000 124 ns/op 96 B/op 1 allocs/op BenchmarkStringConcat/Len100-8 1000000 1152 ns/op 976 B/op 1 allocs/op BenchmarkStringConcat/Len1000-8 100000 11428 ns/op 9776 B/op 1 allocs/op
注意三点：
- 末尾的
-8表示 GOMAXPROCS=8，不是 CPU 核心数，而是当前调度器配置；如需固定，加-cpu=4 - 每行的
ns/op是该子项独立测算的平均值，可直接横向对比 - 若某子项
allocs/op突增，往往意味着逃逸分析失效或意外触发堆分配，值得用go build -gcflags="-m"检查
表驱动本身不解决算法复杂度问题，但它让差异暴露得更干净——尤其是当某个输入规模突然导致性能断层时，你一眼就能定位到临界点。
