Go 的基准测试，远不止是写个循环跑几遍那么简单。不加 -benchmem、不跑多轮、不隔离调度干扰，那些 ns/op 数字再漂亮，也可能只是假象。今天就来聊聊，怎么让 Benchmark 真正说明问题。
为什么 Benchmark 函数总不被 go test -bench 扫到
最让人头疼的“静默跳过”——命令跑完了，你的函数名根本没出现，也不报错。根本原因就四条，缺一不可：
- 函数名必须以
Benchmark开头，后面接大驼峰（比如BenchmarkMapRange），不能小写、不能下划线、不能空格。 - 参数类型必须是
*testing.B，写成testing.B或*testing.T都无效。 - 文件名必须是
*_test.go，放在普通.go文件里不会被扫描。 - 包名必须和待测代码一致，跨包调用需要导出且 import 正确。
验证方法很简单：在函数开头临时加一行 b.Log("hit")，如果没输出，那基本就是上面某条没满足。
怎么写一个真正可比的 Benchmark 函数
可比的前提是“只让算法差异生效”，其他所有变量都得锁死：
- 初始化（造数据、建结构体、预热）必须全写在
b.ResetTimer()之前；计时只从这行之后开始。 - 被测逻辑必须严格放在
for i := 0; i < b.N; i++循环内，不能提前return，也不能漏掉b.N。 - 输入数据必须完全一致：建议在
func init()中生成一次，或用固定 seed 的rand.New构造，避免每次运行分布不同。 - 禁止在循环里调用
fmt.Println、time.Now()、rand.Intn()等非确定性操作——它们不仅慢，还会强制保留计算，引入巨大噪声。
一个典型反模式：for i := 0; i < b.N; i++ { data := make(map[int]int); data[1] = 1; for range data {} } —— 这测的是 make + 遍历，不是纯遍历。
运行命令少一个参数，结论就可能翻车
默认 go test -bench=. 跑出来的数字抖动极大，尤其在笔记本或 CI 上。必须组合使用这些参数：
-benchmem：必须加，否则看不到B/op和allocs/op—— 一个函数快 10%，但allocs/op高 5 倍，高频调用下 GC 可能直接拖垮服务。-count=5：强制跑 5 轮，go test自动取中位数，过滤异常值。-benchtime=5s：每轮至少跑满 5 秒，避免因太快导致采样不准（比如默认 1 秒只跑了 10 万次，误差 ±15%）。GOMAXPROCS=1：排除 goroutine 调度干扰，纯看算法/内存行为差异。
推荐完整命令：GOMAXPROCS=1 go test -bench=. -benchmem -count=5 -benchtime=5s。少一个参数，都可能把真实优化判成“没变化”，或者把噪声当成“提升”。
为什么不能直接比两次 go test -bench 的输出
单次运行受 CPU 频率波动、GC 暂停、后台进程干扰太强，1240 ns/op vs 1190 ns/op 这种 4% 差距，大概率只是随机抖动。真正要判断“有没有变快”，得靠统计显著性检验：
- 别用已废弃的
benchcmp，它只算均值比，没做任何统计。 - 用
benchstat：Go 1.21+ 默认自带，旧版本需go install golang.org/x/perf/cmd/benchstat@latest。 - 两组数据必须用**完全一致的参数**生成：
go test -bench=BenchmarkFoo -count=5 -benchmem -benchtime=5s > old.txt，改完再跑一遍存成new.txt。 benchstat old.txt new.txt输出中，p=0.003表示差异显著，-8.23%表示新版本快约 8%。
最容易被忽略的一点：benchstat 对比的是整个文件里的所有匹配项，如果你在 old.txt 里混了其他 benchmark 结果，它会一起算进去，导致误判。务必用正则精确限定，比如 -bench=^BenchmarkSliceFilter$。
