Go原生支持基准测试，需将函数定义为func BenchmarkXxx(b *testing.B)并置于xxx_test.go中，循环使用b.N而非硬编码，避免误用TestXXX命名或遗漏b.ResetTimer()。
用 go test -bench 运行基准测试
Go 原生支持基准测试，不需要额外依赖。只要测试文件名以 _test.go 结尾，函数名以 Benchmark 开头、接收 *testing.B 参数，go test 就能识别并运行它。
常见错误是把基准函数写成 TestXXX 形式，或漏掉 b.ResetTimer() 导致初始化逻辑被计入耗时。
- 基准测试必须放在
xxx_test.go文件中 - 函数签名严格为
func BenchmarkXxx(b *testing.B) - 循环体必须用
b.N控制次数，不能硬写for i := 0; i - 若需预热或初始化（如构造大数组），应放在
b.ResetTimer()之前
func BenchmarkBinarySearch(b *testing.B) {
data := make([]int, 10000)
for i := range data {
data[i] = i
}
b.ResetTimer() // 初始化完成，从此开始计时
for i := 0; i < b.N; i++ {
binarySearch(data, 5000)
}
}
testing.B 的关键方法和陷阱
b.N 不是固定次数，而是由 Go 自动调整的迭代数，目标是让单次运行时间足够长（默认 ≥ 1 秒），从而减少测量误差。这意味着不同算法、不同输入规模下，b.N 值可能差异极大，不能直接比较原始耗时，要看 ns/op。
容易忽略的是 b.ReportAllocs() 和 b.SetBytes() ——前者开启内存分配统计，后者让输出中的 B/op 有实际意义（比如你每次处理 1KB 数据，就调 b.SetBytes(1024)）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
b.StopTimer()和b.StartTimer()用于临时暂停/恢复计时（比如跳过结果校验） - 避免在循环内做
fmt.Println或写文件，会严重污染结果 - 如果算法依赖随机性（如快排 pivot 随机选），记得用固定 seed，否则每次
b.N调整后行为不一致
对比多个算法变体：用子基准测试
想对比 mergeSort 和 quickSort 在同一数据上的表现？不要写两个独立的 Benchmark 函数——它们可能用不同 b.N，无法横向比 ns/op。应该用 b.Run() 组织子测试，确保每组使用相同 b.N 和相同输入。
子测试还能帮你快速定位性能拐点，比如按输入长度分组：BenchmarkSort/size-100、BenchmarkSort/size-1000。
- 每个
b.Run(name, fn)是独立计时单位，但共享外层b.N的总预算 - 子测试名建议含关键变量（如
"iterative"、"recursive"），方便 grep 筛选 - 数据生成逻辑应在外层完成，避免重复分配；子测试里只做算法调用
func BenchmarkSort(b *testing.B) {
data := make([]int, 1000)
for i := range data {
data[i] = rand.Intn(1000)
}
b.Run("MergeSort", func(b *testing.B) {
for i := 0; i < b.N; i++ {
d := append([]int(nil), data...) // 复制一份
mergeSort(d)
}
})
b.Run("QuickSort", func(b *testing.B) {
for i := 0; i < b.N; i++ {
d := append([]int(nil), data...)
quickSort(d)
}
})
}
真实场景下的干扰项怎么排除
本地跑出的 ns/op 受 CPU 频率波动、后台进程、GC 活动影响很大。单纯一次 go test -bench=. 结果不可靠。
真正有用的流程是：先用 -benchmem 看内存分配，再用 -count=5 -benchtime=3s 多轮采样，最后用 benchstat（需 go install golang.org/x/perf/cmd/benchstat@latest）做统计分析。
-
-benchmem显示B/op和allocs/op，高频小对象分配会显著拖慢 GC -
-benchtime=5s让每轮至少跑 5 秒，比默认 1 秒更稳 - 避免在笔记本上插电/未插电混着测，CPU 省电策略会让结果飘忽
- 如果算法涉及 channel 或 goroutine，注意
GOMAXPROCS设置是否一致
ns/op 数字。缓存局部性、分支预测失败、TLB miss 这些底层因素，不会直接出现在测试报告里，但会决定算法在生产环境是否真的快。 
