Benchmark 函数必须接收 *testing.B 参数，因为 go test -bench 通过 B.N 控制执行次数并自动调优，忽略 B.N 会导致基准测试失效。
为什么 Benchmark 函数必须接收 *testing.B 参数
Go 的基准测试不是靠你手动写 for 循环计时，而是由 go test -bench 驱动调用 B.N 次目标代码。框架会自动调整 B.N 值（从 1 开始指数增长），直到单次运行时间稳定在约 1 秒左右，再统计总耗时。如果你忽略 B.N、硬写 for i := 0; i ，结果就完全不可比，go test 甚至可能报 benchmarked function does not call b.N 错误。
-
B.N是动态值，每次运行可能不同，不能假设为固定数字 - 必须把待测逻辑放在
for i := 0; i 内部，否则不被计入测量范围 - 如果逻辑含初始化开销（如构建 map、分配 slice），应移到
b.ResetTimer()之前，避免污染测量
testing.B 中 ResetTimer、StopTimer、StartTimer 的真实用途
它们不是“暂停/恢复计时器”这种字面意思，而是控制「哪些代码段参与最终的纳秒级耗时统计」。默认整个函数体都计时；但你常需要排除 setup 或 cleanup 代码。
-
b.StopTimer()：停止统计，后续代码不计入耗时（比如预热缓存、构造大数据） -
b.StartTimer()：恢复统计（通常紧跟在准备动作之后） -
b.ResetTimer()：清空已累计的耗时 + 重置迭代计数，**常用于跳过预热阶段**（例如前 100 次不计入，之后才开始正式计时）
func BenchmarkMapAccess(b *testing.B) {
m := make(map[int]int)
for i := 0; i < 10000; i++ {
m[i] = i * 2
}
b.ResetTimer() // 丢弃上面建 map 的时间，从这里重新开始计时
for i := 0; i < b.N; i++ {
_ = m[i%10000] // 实际被测操作
}
}如何避免常见陷阱：内存分配、逃逸、编译器优化
Go 编译器可能把无副作用的计算整个优化掉，导致测出 “0 ns/op”。同时，频繁分配会触发 GC，干扰真实性能。关键是要让结果“强制存活”且“不可省略”。
- 用
blackhole变量承接返回值：result := expensiveFunc(); blackhole = result，其中var blackhole interface{} - 禁用内联可加
//go:noinline注释（仅调试用，勿提交） - 检查是否逃逸：
go build -gcflags="-m" your_bench.go，避免意外堆分配 - 不要在循环里用
fmt.Println、log.Print—— I/O 会严重拖慢并掩盖真实瓶颈
运行与解读 go test -bench 输出的关键字段
输出形如 BenchmarkSort-8 1000000 1245 ns/op 32 B/op 1 allocs/op，每个字段都有明确含义：
立即学习“go语言免费学习笔记（深入）”；
-
BenchmarkSort-8：函数名 + GOMAXPROCS 值（-8 表示用了 8 个 OS 线程） -
1000000：实际执行了b.N次（不是你写的固定数） -
1245 ns/op：每次操作平均耗时（核心指标） -
32 B/op：每次操作分配多少字节内存 -
1 allocs/op：每次操作发生几次堆分配（越少越好）
对比多个 benchmark 时，务必用 go test -bench=. -benchmem -count=5 多次运行取中位数，单次结果波动大。别只看 ns/op，B/op 和 allocs/op 在高并发或长周期服务里影响更大。
