Go原生支持基准测试，需在_test.go文件中定义以Benchmark开头、接收*testing.B参数的函数；运行go test -bench=.执行全部，-bench=BenchmarkName指定单个，-benchmem查看内存分配，-benchtime调整时长；b.N为动态迭代次数，必须参与实际计算以防编译器优化。

用 go test -bench 启动基准测试

Go 原生支持基准测试，不需要额外依赖。只要在测试文件中写一个形如 BenchmarkXXX(*testing.B) 的函数，就能被 go test -bench 自动识别并执行。

注意：测试文件名必须以 _test.go 结尾，且函数名必须以 Benchmark 开头、接收 *testing.B 参数。

• 运行全部基准测试：go test -bench=.
• 只跑某个函数：go test -bench=BenchmarkMapAccess
• 加 -benchmem 可同时查看内存分配次数和字节数
• 默认每个 benchmark 至少运行 1 秒；可通过 -benchtime=5s 手动延长

写可比、不被编译器优化掉的基准函数

常见错误是操作太简单，被编译器内联或直接优化成常量，导致结果失真。比如 b.N 没参与计算、变量未使用、循环体为空。

*testing.B 的 b.N 是框架动态决定的迭代次数，必须把它作为循环上限，并确保每次迭代都产生实际效果（例如写入局部变量、调用非内联函数、触发内存分配）。

• ❌ 错误示例（会被优化）：

  func BenchmarkBad(b *testing.B) {
      for i := 0; i < b.N; i++ {
          _ = 1 + 2 // 常量折叠，整段消失
      }
  }

• ✅ 正确示例（强制参与计算）：

  func BenchmarkGood(b *testing.B) {
      var sum int
      for i := 0; i < b.N; i++ {
          sum += i
      }
      _ = sum // 防止整个循环被删
  }

• 如果测试 map 查找，记得先初始化好 map，不要把建 map 的开销算进每次迭代

对比多个实现时用相同输入和控制变量

要公平比较 A 和 B 两个函数（比如 strings.ReplaceAll vs 手写 strings.Builder 循环），必须保证它们处理完全相同的输入数据，且不因缓存、GC、预热不足引入偏差。

• 把输入数据（如字符串、切片）定义在 Benchmark 函数外或 b.ResetTimer() 之前，避免重复初始化计入耗时
• 用 b.ReportAllocs() 统一开启内存统计
• 必要时调用 runtime.GC() 和 debug.FreeOSMemory()（谨慎！仅用于排除 GC 干扰）
• 多次运行取中位数更稳，但 go test -bench 默认已做多次采样并输出平均值

识别真实瓶颈：别只看 ns/op

ns/op 看起来直观，但容易误导。尤其当函数分配大量内存时，B 值小但 allocs/op 高，可能在高并发下拖垮 GC。

典型陷阱：用 fmt.Sprintf 替代 strconv.Itoa，前者快 2 倍但多分配 3 次对象，长期运行反而更慢。

• 务必加 -benchmem，关注 B/op 和 allocs/op
• 用 -cpuprofile=cpu.pprof 和 -memprofile=mem.pprof 导出分析文件，再用 go tool pprof 深挖热点
• 如果两个实现 ns/op 相差不到 5%，基本可视为无差异；优先选可读性/维护性更好的那个

真正难的是让不同实现共享同一份输入状态又不互相污染——比如测试 channel 吞吐量时，发送端和接收端的 goroutine 调度顺序不可控，这时候单靠 go test -bench 得出的数字意义有限。