Go基准测试函数名必须以Benchmark开头且接收testing.B参数；正确写法为func BenchmarkXxx(b testing.B){...}，b.N由框架自动控制循环次数。
Go 基准测试函数名必须以 Benchmark 开头且接收 *testing.B
Go 的 go test -bench 只会识别形如 BenchmarkXXX(t *testing.B) 的函数。名字不以 Benchmark 开头、参数类型不是 *testing.B、或者多于一个参数，都会被忽略——不会报错，但也不会运行。
常见错误包括：
- 写成
BenchmarkSum(b testing.B)（缺少指针） - 写成
TestBenchmarkFoo(t *testing.B)（前缀不对） - 写成
BenchmarkWithCtx(ctx context.Context, b *testing.B)（参数顺序/数量错误）
正确写法只有一种：func BenchmarkXxx(b *testing.B) { ... }
b.N 是自动控制的循环次数，别手写 for i := 0; i
基准测试的核心是让 Go 运行器决定执行多少轮才能获得稳定统计值。b.N 就是它动态设定的迭代次数，你只需在循环中用它：
立即学习“go语言免费学习笔记（深入）”；
func BenchmarkAdd(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = add(1, 2)
}
}
如果手动固定次数（比如 for i := 0; i ），<code>go test -bench 仍会跑，但结果中的 ns/op 会失真，因为 Go 无法校准开销。更严重的是，当函数极快时，b.N 可能高达百万级；手写固定值会导致单次运行时间过短、误差放大。
额外注意：b.ResetTimer() 要放在初始化代码之后、主循环之前，否则 setup 时间会被计入性能数据。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
避免编译器优化导致函数被内联或消除
如果被测函数太简单（比如 return x + y），Go 编译器可能在构建测试二进制时直接内联甚至整个删掉调用——这时 b.N 循环实际什么也没做，结果会显示异常高的吞吐（例如 0.33 ns/op），毫无参考价值。
解决方法有三个：
- 用
blackhole方式保留结果：将返回值赋给result变量，再用blackhole(result)（其中blackhole是个空函数，参数为interface{}或具体类型） - 禁用内联：在被测函数上加
//go:noinline注释 - 使用真实数据：比如对 slice 做操作时，用
b.Run分不同长度子测试，确保每次都有实际内存访问
例如：
func BenchmarkAddNoInline(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = addNoInline(1, 2)
}
}
//go:noinline
func addNoInline(a, b int) int {
return a + b
}
用 b.Run 组织多组对比测试，别堆多个顶层 Benchmark 函数
当你想比较不同实现（如 map vs sync.Map）、不同参数（如 buffer size = 128/512/2048）时，不要写 BenchmarkMapSmall、BenchmarkMapLarge、BenchmarkSyncMap……这样难以维护，且无法共享 setup 逻辑。
改用 b.Run 子基准：
func BenchmarkCache(b *testing.B) {
for _, size := range []int{128, 512, 2048} {
b.Run(fmt.Sprintf("Size-%d", size), func(b *testing.B) {
cache := NewCache(size)
b.ResetTimer()
for i := 0; i < b.N; i++ {
cache.Get("key")
}
})
}
}
这样输出更清晰（带层级名），支持用 -bench=BenchmarkCache/Size-512 单独跑某组，也方便横向对比。
真正难的是冷热数据分布、GC 干扰、CPU 频率波动这些——它们不会在函数规范里写，但每次 go test -bench=. 前最好关掉无关进程，用 -count=5 多跑几次取中位数，不然看到的可能只是某次运气好的结果。
