Go基准测试是用go test -bench运行的性能验证手段，提供可复现、可对比、防编译器干扰的量化依据；手动测易受干扰且编译器可能删除未使用计算。
go test -bench 运行的、专门测量代码执行耗时与内存开销的性能验证手段，不是“跑一遍看看快不快”，而是为优化提供可复现、可对比、防编译器干扰的量化依据。
为什么不能只靠 time.Now() 手动测？
手动打点容易受初始化、GC、系统调度干扰；更重要的是——Go编译器可能直接删掉你没用到的计算结果。比如：
func BenchmarkBad(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = strings.ToUpper("hello") // 编译器发现返回值没被用，可能整个调用都优化掉
}
}结果看似很快，实则测了个空。真正的基准测试必须让编译器“不敢动”关键路径。
b.ResetTimer() 不是可选项，是保真底线
常见错误：在循环外准备数据（如生成百万元素切片），却没重置计时器，导致初始化时间混入结果。这会让排序算法看起来比实际慢 10 倍以上。
- 正确做法：数据生成完立刻调用
b.ResetTimer() - 如果中间还要预热（如填充缓存、触发 JIT），可用
b.StopTimer()+b.StartTimer()精确包络 - 永远不要在
b.ResetTimer()后再做任何非被测逻辑（如日志、网络请求）
func BenchmarkSort(b *testing.B) {
data := make([]int, 1e5)
for i := range data {
data[i] = rand.Intn(1000)
}
b.ResetTimer() // ✅ 此刻才开始计时
for i := 0; i < b.N; i++ {
SortInsertion(append([]int(nil), data...)) // 避免原地修改影响后续轮次
}
}
看懂输出里的 Allocs/op 和 Bytes/op 才算入门
基准测试默认不报告内存分配，但加一句 b.ReportAllocs() 就能暴露隐藏瓶颈。例如：
-
Allocs/op = 2表示每次操作触发 2 次堆分配——可能是字符串拼接、fmt.Sprintf或未复用的切片 -
Bytes/op = 480表示平均每次操作分配 480 字节，结合 pprof 可定位具体哪行在 malloc - 高频小对象分配会加剧 GC 压力，有时比 CPU 耗时更伤吞吐
func BenchmarkJoin(b *testing.B) {
parts := []string{"a", "b", "c", "d"}
b.ReportAllocs() // ✅ 显式开启内存统计
for i := 0; i < b.N; i++ {
_ = strings.Join(parts, "-")
}
}
别信单次 go test -bench=. 的数字
一次运行受 CPU 频率波动、后台进程、温度降频等影响极大。真实判断需：
- 用
-benchtime=5s延长总运行时长，降低单次抖动权重 - 用
-count=3至少跑 3 轮，再用benchstat工具比对（go install golang.org/x/perf/cmd/benchstat@latest） - 跨机器对比前，务必确认
goos/goarch和 CPU 型号一致，否则纳秒级差异无意义
BenchmarkXxx 函数，而是让那几行被测代码既不被编译器吃掉、又不被初始化污染、还把内存毛刺也暴露出来——这些细节不抠，测得再勤也没法指导优化。 
