Go原生支持基准测试，需用BenchmarkXxx函数对比相同逻辑与输入规模的实现，统一初始化、禁用GC和编译器优化，并以ns/op为关键指标评估性能。
用 go test -bench 跑多个实现的对比基准测试
Go 原生支持基准测试，不需要额外依赖。关键在于把不同实现写成独立的 BenchmarkXxx 函数，并确保它们测试相同逻辑、相同输入规模。Go 会自动对每个函数单独运行、多次采样、排除启动开销。
常见错误是让不同 benchmark 函数使用不同输入数据（比如一个用 make([]int, 100)，另一个用 make([]int, 1000)），这会导致结果不可比。必须统一初始化逻辑，或在 b.ResetTimer() 后再构造输入。
- 所有 benchmark 函数名必须以
Benchmark开头，参数为*testing.B - 用
b.Run()可嵌套子测试，适合对比同一接口的多种实现（如MapSum的 slice vs map 版本） - 避免在
b.N循环内做内存分配（如反复make），否则会把分配时间计入耗时；应提前分配好，循环中只做核心操作
func BenchmarkSumSlice(b *testing.B) {
data := make([]int, 1000)
for i := range data {
data[i] = i
}
b.ResetTimer()
for i := 0; i < b.N; i++ {
sum := 0
for _, v := range data {
sum += v
}
_ = sum
}
}
func BenchmarkSumLoop(b *testing.B) {
n := 1000
b.ResetTimer()
for i := 0; i < b.N; i++ {
sum := 0
for j := 0; j < n; j++ {
sum += j
}
_ = sum
}
}
用 benchstat 统计并对比多组结果
go test -bench 单次运行波动大，直接看数字容易误判。真实对比必须跑多次、取统计值。Go 官方工具链提供了 benchstat（需 go install golang.org/x/perf/cmd/benchstat@latest）专门干这事。
它能读取多个 bench 输出文件，计算均值、标准差、显著性差异（p 值），并用 ± 和 ~/+/- 直观标出性能变化趋势。
立即学习“go语言免费学习笔记（深入）”；
- 每次运行用
-count=5至少采样 5 次（推荐 10 次），重定向到不同文件：go test -bench=. -count=10 > old.txt - 修改代码后重新跑：
go test -bench=. -count=10 > new.txt - 执行
benchstat old.txt new.txt，输出里带-2.34%表示新实现快约 2.34%，p=0.001表示差异高度显著
控制变量：禁用 GC、固定 GOMAXPROCS、绕过编译器优化
基准测试结果受运行时干扰极大。默认情况下 GC 可能在任意时刻触发，GOMAXPROCS 可能随系统负载变化，编译器还可能把整个循环优化掉（尤其空循环或无副作用操作）。
- 加
-gcflags="-l -N"禁用内联和优化，防止编译器“猜中”你的意图而删掉实际逻辑 - 在 benchmark 函数开头加
runtime.GC()和debug.SetGCPercent(-1)暂停 GC（记得测完恢复） - 用
runtime.GOMAXPROCS(1)锁定单线程，排除调度抖动；若测并发方案，则显式设为固定值（如 4）并保持一致 - 确保被测操作有可观察副作用（如赋值给全局变量或传入
_ =），否则编译器可能彻底移除该段代码
注意 b.N 不是“执行次数”，而是 Go 自动调节的迭代目标
b.N 是 Go 运行时根据预热结果动态调整的循环次数，目的是让单轮 benchmark 总耗时稳定在约 1 秒左右。它不是你指定的固定值，也不能直接用来算“每秒处理多少条”。误用 b.N 计算吞吐量（比如 b.N / time.Second）是常见错误。
正确做法是：把你要测量的单位操作封装进循环体，让 Go 自动决定 b.N；最终报告的 BenchmarkXxx-8 1000000 1234 ns/op 中的 ns/op 才是核心指标——它表示「每次操作平均耗时」，已由 Go 归一化过。
- 不要在循环里调
b.ReportMetric或打印日志，这会严重污染结果 - 如果操作本身极快（如几个 CPU 指令），Go 可能报
too fast to measure；此时需手动展开（如一次循环做 100 次操作），再把结果除以 100 - 对比不同实现时，务必确认它们的
op语义一致——比如都算“对长度为 N 的切片求和”，而不是一个算 sum，另一个算 len
json），就可能因包级 init 或 type cache 加载而多出几十纳秒抖动。所以，务必让所有待比方案共享前置初始化，或各自 warmup 充分。 
