Go基准测试必须满足四个硬性条件才能被go test -bench识别并执行：文件名以_test.go结尾、函数名以Benchmark开头且首字母大写、参数类型为*testing.B、主逻辑置于for i := 0; i < b.N; i++循环内；缺一则静默跳过，常见现象为no benchmarks to run或输出空白。
Go 基准测试不是写个 BenchmarkXxx 就能信的——不满足硬性条件，go test -bench=. 会静默跳过；不控制计时边界、不防编译器优化、不看内存分配，跑出来的 ns/op 数字基本是噪声。
为什么 go test -bench=. 什么都没输出或显示 0.00 ns/op
最常见原因是函数没满足硬性准入条件：
- 文件名不是
*_test.go（比如放在main.go或utils.go里） - 函数名没以大写
Benchmark开头（benchmark_fib、TestBenchmarkFib、Benchmarkfib全无效） - 参数类型不是
*testing.B（写成func BenchmarkFoo(t *testing.T)或func BenchmarkFoo(b testing.B)都不行） - 循环体里没用
b.N（比如写成for i := 0; i < 1000; i++）
这些错误都不会报错，也不会提示，go test -bench=. 直接当没这回事。现象通常是：no benchmarks to run，或者输出里压根没你的函数名，或者显示 benchmarked 0 times。
如何写一个真正被框架执行的 Benchmark 函数
必须同时满足四个条件，缺一不可：
立即学习“go语言免费学习笔记（深入）”；
- 文件名以
_test.go结尾（如math_test.go） - 函数名是
BenchmarkXxx形式，首字母大写、驼峰命名（如BenchmarkAdd） - 签名严格为
func BenchmarkXxx(b *testing.B) - 主逻辑包裹在
for i := 0; i < b.N; i++循环内
示例（合法）：
func BenchmarkAdd(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = Add(1, 2)
}
}
注意：b.N 是动态值，由框架根据目标耗时（默认约 1 秒）自动调整。你不能把它当常量用，也不能在循环里做 if b.N == 1 初始化——每次运行 b.N 都可能不同。
怎么避免初始化开销污染结果和编译器优化掉逻辑
初始化（如 make(map[int]int, 1e6)、预热 JSON 数据）必须剥离出计时范围，否则 ns/op 变成“初始化 + 执行”的混合值；而无副作用调用会被编译器直接优化成空操作，导致 ns/op 低得反常识（比如 0.32 ns/op），实际根本没跑。
- 用
b.ResetTimer()放在初始化之后、循环之前，确保只测主逻辑 - 用
b.ReportAllocs()放在b.ResetTimer()之后、循环之前，才能统计真实内存分配 - 强制保留计算结果：声明
var blackhole int，然后在循环末尾写blackhole = compute()；或更轻量地写_ = result & 1 - 绝对不要在循环里调
fmt.Println、log.Print或time.Now()——它们虽能防优化，但引入巨大 I/O 噪声
典型结构：
func BenchmarkFibonacci(b *testing.B) {
// 初始化（不计时）
precomputed := make([]int, 40)
for i := 0; i < len(precomputed); i++ {
precomputed[i] = Fibonacci(i)
}
b.ResetTimer() // ✅ 计时从此开始
b.ReportAllocs() // ✅ 内存统计从此开始
for i := 0; i < b.N; i++ {
_ = Fibonacci(35) // ✅ 强制使用返回值
}
}
如何可靠对比两个实现的性能差异
单独跑 BenchmarkA 和 BenchmarkB 然后比 ns/op？完全不可靠。两次运行受 GC 周期、CPU 频率抖动、后台进程干扰完全不同，尤其当分配行为差异大时，数值波动剧烈。
- 必须用
b.Run()在同一个基准生命周期内执行，共享 GC 周期、预热状态、调度上下文 - 加
-benchmem查看B/op和allocs/op，高频调用场景下，哪怕单次多分配 16 字节，每秒百万次就是 16MB/s 堆压力 - 用
-benchtime=5s延长总时长，减少计时抖动；慎用-cpu，普通函数设了也没用
横向对比应这样写：
func BenchmarkStringConcat(b *testing.B) {
b.Run("plus", func(b *testing.B) {
s := "hello"
b.ReportAllocs()
b.ResetTimer()
for i := 0; i < b.N; i++ {
_ = s + " world"
}
})
b.Run("builder", func(b *testing.B) {
var builder strings.Builder
s := "hello"
b.ReportAllocs()
b.ResetTimer()
for i := 0; i < b.N; i++ {
builder.Reset()
builder.WriteString(s)
builder.WriteString(" world")
_ = builder.String()
}
})
}
微基准测试最容易被忽略的，是它根本不是“测一次就完事”的工具——它极度依赖上下文一致性。哪怕只是多开一个浏览器标签页，都可能让 ns/op 波动 10% 以上。真要定位瓶颈，得反复验证、交叉对照、排除干扰，而不是盯着单次输出里的那个数字。
