go基准测试需满足四条件：函数名以benchmark开头且大驼峰、参数为*testing.b、文件名含_test.go、包名一致；初始化在b.resettimer()前，逻辑在b.n循环内，禁用非确定性操作；必加-benchmem、-count=5、-benchtime=5s、gomaxprocs=1；用benchstat做显著性检验。
Go 的 benchmark 不是写个循环跑几次就能得出可靠结论的——不加 -benchmem、不跑多轮、不隔离调度干扰，ns/op 数字再小也可能是假象。
为什么 Benchmark 函数总不被 go test -bench 扫到
静默跳过是最常见的“没跑起来”现象，根本原因就四条，缺一不可：
- 函数名必须以
Benchmark开头，后面接大驼峰（如BenchmarkMapRange），不能小写、不能下划线、不能空格 - 参数类型必须是
*testing.B，写成testing.B或*testing.T都无效 - 文件名必须是
*_test.go，放在普通.go文件里不会被扫描 - 包名必须和待测代码一致，跨包调用需导出且 import 正确
典型错误现象：go test -bench=. 输出里压根没有你的函数名，也不报错。验证方法：临时加一行 b.Log("hit") 在函数开头，如果没输出，基本就是上面某条没满足。
怎么写一个真正可比的 Benchmark 函数
可比的前提是「只让算法差异生效」，其他所有变量都得锁死：
- 初始化（造数据、建结构体、预热）必须全写在
b.ResetTimer()之前；计时只从这行之后开始 - 被测逻辑必须严格放在
for i := 0; i 循环内，不能提前 <code>return、不能漏掉b.N - 输入数据必须完全一致：建议在
func init()中生成一次，或用固定 seed 的rand.New构造，避免每次运行分布不同 - 禁止在循环里调用
fmt.Println、time.Now()、rand.Intn()等非确定性操作——它们不仅慢，还会强制保留计算，引入巨大噪声
反模式示例：for i := 0; i —— 这测的是 <code>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$。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
