必须使用 b.N 循环，Go 的 Benchmark 函数通过 b.N 控制重复执行次数以获得稳定统计值；若未将待测逻辑置于循环内，基准测试结果无效。
不写 b.N 循环，基准测试就等于没测
Go 的 Benchmark 函数不是“执行一次看耗时”，而是靠 b.N 控制重复次数来压出稳定统计值。如果你把待测逻辑直接写在函数体里、没包进 for i := 0; i ，那 <code>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())（需 importruntime） - 验证技巧：加
go build -gcflags="-l"关闭内联，再跑 benchmark，若结果突变，说明原来被优化了
最常被忽略的不是某行代码怎么写，而是环境本身——CPU 频率缩放、后台进程、笔记本电源模式，都能让 ns/op 波动 ±30%。真要定位回归，得关掉 Turbo Boost、禁用其他应用、跑三次以上取平均，否则你调优的只是噪声。
