17370845950

必须使用 b.N 循环，Go 的 Benchmark 函数通过 b.N 控制重复执行次数以获得稳定统计值；若未将待测逻辑置于循环内，基准测试结果无效。

不写 b.N 循环，基准测试就等于没测

Go 的 Benchmark 函数不是“执行一次看耗时”，而是靠 b.N 控制重复次数来压出稳定统计值。如果你把待测逻辑直接写在函数体里、没包进 for i := 0; i ，那 go test -bench=. 实际只运行了一次，但报告的 ns/op 是拿总时间除以一个可能高达上亿的 b.N——结果就是 0.3 ns/op 这种假高光数据，毫无意义。

• 错误写法：func BenchmarkFoo(b *testing.B) { doWork() }（doWork() 只跑一次）
• 正确写法：func BenchmarkFoo(b *testing.B) { for i := 0; i
• 更安全写法：初始化放循环外，再用 b.ResetTimer() 切掉准备时间

b.ResetTimer() 不调，初始化开销就混进性能数字里

比如你要测排序 10 万元素切片的性能，却在 for 循环里每次生成新切片、填充随机数——这些内存分配和随机计算全被算进 ns/op，你其实测的是“生成+排序”，不是“纯排序”。真实瓶颈可能根本不在排序算法本身。

• 典型场景：构建大 []byte、加载配置、预热缓存、初始化 map 等
• 必须动作：在初始化完成后、循环开始前加 b.ResetTimer()
• 额外提醒：如果初始化后还要做少量预热操作（比如首次调用触发 JIT 或 cache warmup），可用 b.StopTimer() + b.StartTimer() 精确掐段

结果没用 b.ReportAllocs()，内存压力就完全看不见

ns/op 再低也没用，如果每次操作都分配 1KB 内存，GC 就会拖垮服务。而 Go 默认不报告内存指标，allocs/op 和 B/op 全是 0——这不是没分配，是没开报告。

• 必加语句：b.ReportAllocs()，放在函数开头即可
• 常见误分配点：strings.Builder{} 每次新建、&

  

  Struct{} 在循环里、make([]byte, n)（应改用 make([]byte, 0, n)）
• 验证方式：加了 -benchmem 参数后，输出里出现类似 500 B/op 2 allocs/op 才算生效

编译器优化一削，测的其实是“空函数”

如果你的被测函数返回一个值，但这个值没被任何地方使用，Go 编译器大概率直接删掉整个调用链。你看到的 0.5 ns/op，其实是空循环的开销。

• 现象：ns/op 异常低（B/op 为 0、不同算法差距极小
• 解决方法一（推荐）：用全局变量兜住结果，例如 var blackhole int; blackhole = compute()
• 解决方法二：用 runtime.KeepAlive(compute())（需 import runtime）
• 验证技巧：加 go build -gcflags="-l" 关闭内联，再跑 benchmark，若结果突变，说明原来被优化了

最常被忽略的不是某行代码怎么写，而是环境本身——CPU 频率缩放、后台进程、笔记本电源模式，都能让 ns/op 波动 ±30%。真要定位回归，得关掉 Turbo Boost、禁用其他应用、跑三次以上取平均，否则你调优的只是噪声。