Go基准测试函数必须以Benchmark开头且接收*testing.B参数；b.N由框架动态调整，不可手动赋值或修改，否则导致结果失真。
Go基准测试函数必须以 Benchmark 开头且接收 *testing.B
Go 的 go test -bench 只会识别形如 BenchmarkXXX(t *testing.B) 的函数。名字不以 Benchmark 开头、参数类型不是 *testing.B，或漏掉指针符号（比如写成 testing.B），都会被忽略——不会报错，但也不会运行。
常见错误包括：
- 函数名拼错，如
BenchMarkAdd（大小写错）或TestBenchmarkAdd（混入Test前缀） - 参数写成
b testing.B（非指针），导致编译通过但-bench找不到 - 在
main包里写基准测试（必须在test文件中，即文件名以_test.go结尾）
b.N 是自动调整的循环次数，不要手动设初值或重置
b.N 是 Go 测试框架为达到稳定耗时而动态决定的执行轮数，通常从 1 开始试探，逐步翻倍，直到单次运行时间足够长（默认 ≥ 100ms）。你不能用 b.N = 1000 强制固定次数，也不能在循环外修改它——这会破坏基准逻辑，让结果失真。
正确写法只有一种：
func BenchmarkAdd(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = add(1, 2)
}
}
注意点：
- 所有待测逻辑必须放在
for循环体内，且循环上限严格为b.N - 避免在循环内做初始化（如新建 map、打开文件），应提至
for外；否则初始化开销会被计入耗时 - 如果函数有副作用（如修改全局变量），需在每次迭代中重置状态，否则后续迭代结果可能被污染
用 b.ResetTimer() 排除 setup 开销
当基准测试需要预热数据（如构造大 slice、解析 JSON、建立连接），这部分代码不应计入性能统计。Go 提供 b.ResetTimer() 来重置计时器起点。
典型结构如下：
func BenchmarkJSONUnmarshal(b *testing.B) {
data := []byte(`{"name":"foo","age":42}`)
b.ResetTimer() // ⚠️ 计时从此开始
for i := 0; i < b.N; i++ {
var u map[string]interface{}
json.Unmarshal(data, &u)
}
}
关键规则：
-
b.ResetTimer()必须在for循环之前调用，且只能调用一次（多次调用无意义，也不会报错） - 不能在循环体内调用，否则每次迭代都重置，最终耗时接近 0
- 如果 setup 部分本身很慢（如启动 HTTP server），可配合
b.StopTimer()+b.StartTimer()精确控制区间
运行时加 -benchmem 查看内存分配，避免隐式逃逸
仅看 ns/op 不够——高频小对象分配会触发 GC 压力，拖慢真实场景。加 -benchmem 能显示每次操作的内存分配次数（B/op）和字节数（allocs/op）。
例如：
$ go test -bench=BenchmarkAdd -benchmem BenchmarkAdd-8 1000000000 0.25 ns/op 0 B/op 0 allocs/op
容易被忽略的坑：
- 返回局部变量地址（如
&x）、闭包捕获大变量、切片扩容，都可能导致变量逃逸到堆，增加allocs/op - 使用
go tool compile -gcflags="-m" xxx_test.go可查看逃逸分析详情 - 若发现意外分配，优先检查是否误用了指针、是否可改用栈上数组（如
[64]byte替代[]byte）
基准测试真正难的不是写循环，而是确保测的是你想测的那部分——setup 和 teardown 的边界、内存行为、并发干扰，稍不注意，数据就不可信。
