用 go test -bench 对比两个实现需确保数据一致、初始化不计时：预生成数据放 init() 或 Benchmark 开头，调用 b.ResetTimer()；结果必须被使用（如 _ = result）；导出结果用 > old.txt/> new.txt，再用 benchcmp 比较；加 -count=3 -benchtime=5s 提升稳定性；必加 -benchmem 关注 allocs/op 和 B/op。
怎么用 go test -bench 直接对比两个实现？
核心是让两个 Benchmark 函数处理**完全相同的数据规模和结构**，且初始化逻辑不计入计时。比如对比切片遍历和 map 查找，必须用同一组数字（1~1000），不能一个用 []int、另一个用 map[int]bool 但 key 分布不同。
- 预生成数据推荐放在
func init()或 Benchmark 函数开头，再用b.ResetTimer()切掉准备时间 - 避免在循环里调用
rand.Intn()或time.Now()—— 这会引入噪声，还可能被编译器优化掉 - 结果必须“被使用”，否则 Go 1.21+ 编译器可能直接删掉整条调用链；常见做法是赋值给
_或局部变量后加_ = result
如何导出并横向比对多次运行结果？
单次 go test -bench=. 输出只是当前快照，没法看出性能漂移。真正做版本对比，得把旧版基准存成文件，再和新版比。
- 先跑老代码：
go test -bench=. -benchmem > old.txt - 改完代码后：
go test -bench=. -benchmem > new.txt - 用官方推荐工具
benchcmp对比：benchcmp old.txt new.txt
输出中像 BenchmarkMapLookup 20000000 62.3 ns/op → 21000000 58.1 ns/op -6.7% 这样的行，负号表示变快了；正号（如 +11.76%）才是性能退化，CI 应该告警或阻断合并。
为什么 -count=3 和 -benchtime=5s 不可少？
b.N 是动态调整的，但单次运行受系统负载、CPU 频率波动影响大。只跑一次容易误判——比如某次刚好被 Docker 容器抢占了 CPU，结果虚高。
-
-count=3：强制运行 3 轮，go test会自动取中位数，过滤异常值 -
-benchtime=5s：让每轮至少跑满 5 秒，而不是默认的 1 秒，提升统计稳定性 - 组合使用更稳妥：
go test -bench=. -benchmem -count=3 -benchtime=5s
内存分配差异怎么抓？光看 ns/op 不够
有些函数看似快，但每 op 分配几十次堆内存，高频调用下 GC 压力陡增。这时必须加 -benchmem，重点盯 allocs/op 和 B/op。
func BenchmarkJSONUnmarshal(b *testing.B) {
data := []byte(`{"name":"alice","age":30}`)
b.ResetTimer()
for i := 0; i < b.N; i++ {
var u struct{ Name string; Age int }
_ = json.Unmarshal(data, &u)
}
}
如果输出是 1000000 1240 ns/op 240 B/op 4 allocs/op，就要警惕：4 次分配意味着至少触发了 4 次堆内存申请，而如果换成预分配的 sync.Pool 或 json.Decoder 复用，可能压到 0 allocs/op。
最常被忽略的是：不同 Go 版本间 b.N 的自适应策略有微小变化，跨版本对比必须确保 Go 环境一致；另外 CI 机器若没锁频、没清缓存，哪怕同一份代码，ns/op 波动 ±5% 也属正常 —— 所以设阈值时别卡死在 ±1%，留点余量。
