Benchmark函数需以Benchmark开头、参数为*testing.B、文件名以_test.go结尾；用-bench=.运行，benchstat对比结果，关注B/op和allocs/op而非仅ns/op。
怎么写一个能被 go test -bench 识别的 Benchmark 函数
Go 的 benchmark 不是随便起个函数名就能跑的——它必须严格满足签名和命名规则，否则 go test -bench=. 会直接跳过，还不报错。
- 函数名必须以
Benchmark开头，后接大驼峰（如BenchmarkMapRange），不能小写、不能下划线 - 参数类型必须是
*testing.B，写成*testing.T或testing.B都无效 - 文件名必须是
*_test.go，放在普通.go文件里不会被扫描到 - 待测逻辑必须包在
for i := 0; i 循环里，不能提前 return、也不能漏掉 <code>b.N
常见错误现象：BenchmarkFoo-8 0 0.00 ns/op 或完全不输出该函数——大概率是上面某条没守牢。
为什么 b.ResetTimer() 一定要放在初始化之后
因为 b.N 是动态调整的，Go 会先试跑几轮估算单次耗时，再放大次数让总时间接近 1 秒（默认）。如果把数据构造、map 初始化等写在循环里，测出来的就不是“遍历”，而是“创建 + 遍历”。
- 初始化代码（如
data := make(map[int]int)、预填数据）必须写在b.ResetTimer()之前 - 如果算法有隐式预热需求（比如首次 map 写入触发扩容），可手动跑一两轮再调
b.ResetTimer() - 切忌在循环里重复
make、new、或从外部读配置——这些都会污染ns/op
示例反模式：for i := 0; i —— 这测的是内存分配器速度，不是你的算法。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
怎么避免编译器把关键计算“优化掉”
Go 编译器太聪明，如果它发现你算完结果没用，整个循环可能被删成空操作。典型表现是 0.32 ns/op 这种反常识数字，或者 b.N 高得离谱（上亿次）。
- 把关键中间结果赋给包级变量（如
var blackhole int），再在循环末尾写blackhole = sum - Go 1.21+ 可用
b.ReportMetric(0, "op")或直接对结果做无害副作用（如_ = sum & 1） - 别用
fmt.Println、time.Now()、log.Print等 I/O 操作——它们不仅慢，还会强制保留计算，但引入巨大噪声
验证方法：加 -gcflags="-m" 看逃逸分析，确认变量是否真被使用；或者临时注释掉赋值语句，看 ns/op 是否骤降为 0。
用 benchstat 对比时，为什么单次 go test -bench 结果不可信
一次运行受 GC 停顿、CPU 频率波动、后台进程干扰太大。benchstat 不是“取平均”，而是做统计显著性检验（t-test），告诉你提升是不是真发生了，而不是随机抖动。
- Go 1.21+ 自带
benchstat，旧版本需go install golang.org/x/perf/cmd/benchstat@latest - 必须用相同参数跑多轮：
go test -bench=. -benchmem -count=5 > v1.txt，再改代码跑v2.txt - 对比命令是
benchstat v1.txt v2.txt，输出里−23.45%表示快了约 23%，~表示无显著差异 - 别混用
-benchtime或不同GOMAXPROCS，benchstat会拒绝解析格式不一致的输入
真正容易被忽略的点：很多人只盯着 ns/op，但 B/op 和 allocs/op 才决定高并发下的稳定性——一次快 10%，但内存分配翻倍，QPS 可能在压测中直接崩掉。
