基准测试函数必须以Benchmark开头且接收*testing.B参数；常见错误包括参数类型错误、前缀小写、漏调b.ResetTimer()或在循环外初始化，b.N由框架自动调整。
基准测试函数必须以 Benchmark 开头且接收 *testing.B
Go 的基准测试不是随便起个函数名就能跑的，必须严格满足两个条件：函数名以 Benchmark 为前缀（如 BenchmarkMapAccess），且唯一参数类型是 *testing.B。否则 go test -bench 会直接忽略它。
常见错误包括：
- 写成
func BenchmarkMapAccess(t *testing.T)—— 参数类型错，会被当成普通测试，-bench不识别 - 写成
func benchMapAccess(b *testing.B)—— 前缀小写，不被发现 - 漏掉
b.ResetTimer()或在b.N循环外做了初始化操作，导致初始化开销混入测量结果
b.N 是自动调整的迭代次数，别手动写死循环
Go 基准测试会先预热，再根据目标耗时（默认 1 秒）动态调整 b.N 值，让总执行时间稳定可比。你只需在 b.ResetTimer() 后用 for i := 0; i 包裹待测逻辑。
错误做法：
- 写
for i := 0; i —— 失去自动调优能力，不同机器/函数间不可比 - 在
for循环里调用b.ReportAllocs()或b.SetBytes()—— 应放在循环外一次性设置 - 忘记调用
b.ReportAllocs()就想看内存分配，结果allocs/op显示为0
避免在基准测试中触发 GC 或阻塞操作
任何非目标逻辑的额外开销都会污染结果。比如在循环里反复 make([]int, n)、fmt.Sprintf、或调用 time.Sleep，不仅放大内存分配，还可能让 runtime 插入 GC，导致 ns/op 波动极大甚至失真。
实操建议：
- 初始化放
b.ResetTimer()之前（如构造 map、slice、预分配缓冲） - 如果必须测带内存分配的操作，用
b.ReportAllocs()+b.SetBytes(int64(len(data)))辅助解读 - 禁止在
for循环内做文件 I/O、网络请求、锁竞争等非 CPU-bound 行为 —— 这类场景应改用集成压测工具
运行和解读 go test -bench 输出的关键字段
执行 go test -bench=^BenchmarkMapAccess$ -benchmem 后，典型输出像：
BenchmarkMapAccess-8 10000000 125.2 ns/op 0 B/op 0 allocs/op
其中：
-
10000000是实际执行的b.N次数 -
125.2 ns/op是每次操作平均耗时（核心指标） -
0 B/op表示每次操作平均分配 0 字节内存（依赖-benchmem和b.ReportAllocs()） -
0 allocs/op是每次操作的堆分配次数
注意：末尾的 -8 表示 GOMAXPROCS=8，多核并行下数值才具参考性；单核机器上跑出的结果不能直接和别人对比。
真正容易被忽略的是——如果你的函数内部有分支逻辑（比如根据输入大小切换算法），而基准测试只喂了固定尺寸数据，那结果只反映该尺寸下的性能，不代表整体行为。得配合多个 BenchmarkXxxSmall/BenchmarkXxxLarge 才能看清拐点。
