Go基准测试是用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 型号一致，否则纳秒级差异无意义