Go基准测试必须用go test -bench触发，函数名以Benchmark开头、参数为*testing.B、文件名含_test.go；b.ResetTimer()重置计时和b.N，b.StopTimer()/StartTimer()控制计时区间。
如何用 go test -bench 正确触发基准测试
Go 的基准测试不是靠手动调用函数，而是必须通过 go test -bench 命令自动发现并执行，且函数签名严格限定为 func BenchmarkXxx(*testing.B)。名字不以 Benchmark 开头、参数类型不对、或放在非 _test.go 文件里，都会被完全忽略。
- 文件名必须是
xxx_test.go（不能是benchmark.go或perf.go） - 函数必须接收
*testing.B参数，不能是*testing.T或其他类型 - 默认只运行
Benchmark.*，想跑特定函数就写go test -bench=^BenchmarkMyFunc$ - 加
-benchmem才会显示内存分配统计，否则b.AllocsPerOp()和b.N无关的内存数据不会输出
b.ResetTimer() 和 b.StopTimer() 的真实用途
它们不是“暂停计时器”这种字面意思，而是控制「计入最终耗时的代码段」——只有在 timer running 状态下执行的代码，才参与 b.N 次循环的平均耗时计算。初始化、预热、结果验证等辅助逻辑应排除在外。
-
b.StopTimer()：停掉计时，可用于 setup 或 cleanup 阶段，比如构建大输入、解析 JSON、初始化 map -
b.StartTimer()：重新开启（不是“继续”，而是新启一个计时窗口） -
b.ResetTimer()：清空已累计耗时 + 重置b.N计数器，常用于跳过冷启动抖动（比如首次 GC、cache miss），但要小心：它会让前序所有循环失效，只从 reset 后开始统计
func BenchmarkJSONUnmarshal(b *testing.B) {
data := []byte(`{"name":"foo","age":42}`)
var u struct{ Name string; Age int }
b.ResetTimer() // 跳过变量声明和 data 构造的开销
for i := 0; i < b.N; i++ {
json.Unmarshal(data, &u) // 这段才被计时
}
}
为什么 b.N 不是固定次数，而要由 Go 自动调整
b.N 是 Go 根据目标耗时（默认 1 秒）动态确定的迭代次数，不是你指定的循环上限。它会先试跑少量次数（如 1、10、100），估算单次耗时，再放大到接近 1 秒的总耗时。这意味着：
- 同一函数在不同机器、不同负载下
b.N可能差几倍，不能硬编码依赖它的值 - 如果函数本身极快（纳秒级），
b.N可能达到百万甚至千万级，此时要注意整数溢出、内存缓存效应干扰 - 若函数含阻塞操作（如
time.Sleep、网络请求），Go 可能因超时直接中止，报错too many iterations，这时得用b.SetBytes()或手动控制循环 - 避免在循环体内做条件判断或分支跳转，尤其是基于
i % 100 == 0这类逻辑——它会污染 CPU 分支预测，让结果失真
对比多个实现时，如何避免编译器优化干扰
Go 编译器会对未使用的返回值、无副作用的变量赋值做删除（dead code elimination）。如果你只测函数执行，但没用到返回值，整个调用可能被优化掉，导致基准结果为 0 ns/op。
立即学习“go语言免费学习笔记（深入）”；
- 强制保留结果：用
blackhole := fn(...)+blackhole在循环外引用（但别放循环内，否则增加额外开销） - 更可靠方式：用
testing.Benchmark返回值捕获，或直接调用runtime.KeepAlive() - 禁用优化仅用于调试：
go test -gcflags="-l -N" -bench=.，但生产对比务必用默认编译选项 - 对 slice/map 操作要特别注意：
append可能触发底层数组扩容，导致某次迭代突然变慢，建议预先make([]T, 0, cap)固定容量
func BenchmarkMapLookup(b *testing.B) {
m := make(map[string]int)
for i := 0; i < 1000; i++ {
m[fmt.Sprintf("key-%d", i)] = i
}
keys := make([]string, 0, 1000)
for k := range m {
keys = append(keys, k)
}
b.ResetTimer()
var blackhole int
for i := 0; i < b.N; i++ {
blackhole = m[keys[i%len(keys)]] // 强制使用结果
}
runtime.KeepAlive(blackhole) // 防止编译器认为 blackhole 无用
}
实际写基准时，最容易漏掉的是 b.ResetTimer() 的位置和 runtime.KeepAlive() 的配对——前者导致 setup 时间混入测量，后者让整个循环被优化成空操作。这两处一错，数据就完全不可信。 
