Go基准测试需严格满足三要素：函数名以Benchmark开头且驼峰大写、参数为*testing.B、文件为xxx_test.go；必须用b.N循环而非固定次数，否则结果不可信。
Go 的基准测试不是“跑一次看耗时”，而是由 go test -bench 自动控制迭代次数、排除初始化干扰、稳定采样后给出 ns/op 和内存分配数据；写错函数签名、漏掉 b.N 循环、或在循环里做 setup，结果就完全不可信。
func BenchmarkXxx(b *testing.B) 必须严格满足三要素
函数能被识别并执行，只取决于三个硬性条件，缺一不可：
- 函数名以
Benchmark开头，且首字母大写、驼峰命名，例如BenchmarkMapInsert；benchmarkMapInsert、BenchMapInsert、TestBenchmarkMap全部无效 - 参数类型必须是
*testing.B（带星号指针），写成testing.B或*testing.T会编译失败或静默跳过 - 文件必须是同包的
xxx_test.go，不能放在main.go或普通.go文件里
常见现象：no benchmarks to run 或输出里压根没你的函数名——大概率是这三者中某一个没对上，而不是代码逻辑问题。
必须用 b.N 控制循环，不能手写固定次数
b.N 是测试框架根据耗时自动调整的迭代次数，目标是让整个函数运行时间接近默认 1 秒（可用 -benchtime=3s 调整）。你手动写 for i := 0; i 不仅让 <code>b.N 失效，还会导致不同机器、不同环境下的结果无法横向比较。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确写法永远是：
for i := 0; i - 极快的函数（比如纳秒级操作），
b.N可能高达千万甚至上亿——这是正常行为，说明框架在努力压低单次误差 - 别在循环里调
time.Now()或fmt.Println()：前者绕过框架计时，后者触发大量分配和 syscall，污染ns/op和allocs/op
初始化和副作用必须隔离，否则 ns/op 完全失真
像 make([]byte, 1e6)、json.Unmarshal 预热数据、打开临时文件这类操作，如果混在计时区内，就会把 setup 时间摊到每次操作上。尤其当初始化远重于主逻辑时，ns/op 变成“初始化 + 执行”的混合值，毫无参考意义。
- 标准结构是：setup 代码 →
b.ResetTimer()→for i := 0; i { 主逻辑 } - 如果被测逻辑有副作用（比如修改全局 map 或切片），每次迭代前需重置状态，且重置代码也得放在
b.StopTimer()/b.StartTimer()区块内 -
b.ReportAllocs()要在b.ResetTimer()之后调用，否则内存统计包含 setup 阶段
对比两个实现时，别手动比数字
单独跑两次 go test -bench=. 再肉眼对比 ns/op，很容易因系统噪声（后台进程、GC 抖动）得出错误结论。Go 官方已废弃 benchcmp，现在推荐用 benchstat：
- 先保存基线：
go test -bench=^BenchmarkFoo$ -benchmem -count=5 | tee bench-old.txt - 改代码后存新结果：
go test -bench=^BenchmarkFoo$ -benchmem -count=5 | tee bench-new.txt - 运行：
benchstat bench-old.txt bench-new.txt（需先go install golang.org/x/perf/cmd/benchstat@latest）
benchstat 不是比较平均值，而是用 Welch’s t-test 判断性能差异是否统计显著，并给出置信区间——这才是真正可靠的对比方式。很多人卡在第一步：忘了加 -count=5，只跑一次，结果波动太大，根本没法下结论。
