Go基准测试专用于精确测量单个函数执行耗时和内存分配，只回答单次调用平均纳秒数及堆内存分配次数；必须用b.N循环因其由框架动态调整以使总运行时间约1秒。
Go基准测试不是性能压测，而是专用于精确测量单个函数执行耗时和内存分配的内置机制。它不关心QPS、并发能力或系统稳定性，只回答两个问题：这段代码单次调用平均耗多少纳秒？分配几次堆内存？答案直接来自testing包，无需引入任何第三方库。
为什么必须用b.N循环，不能硬编码次数？
基准测试框架会动态调整b.N，目标是让整个for循环稳定运行约1秒（默认值，可用-benchtime修改）。这意味着：
- 快函数（如
int加法）b.N可能是10⁹；慢函数（含time.Sleep(10ms)）可能只有几十 - 硬写
for i := 0; i 会导致时间太短，结果抖动大、统计无效 -
b.N在单次运行中恒定，但跨机器、跨Go版本、甚至GC压力变化时都会不同——所以只比同一环境下的相对值
BenchmarkXxx(b *testing.B)的三个硬约束
缺一不可，否则go test -bench=.会完全忽略该函数：
- 文件名必须以
_test.go结尾，且与被测代码同包 - 函数名必须以
Benchmark开头（如BenchmarkJoin） - 函数体必须包含
for i := 0; i 循环，且被测逻辑必须放在循环内
错误示例：BenchmarkBad(b *testing.B) { strings.Join([]string{"a","b"}, "-") } —— 没循环，不计时、不统计。
立即学习“go语言免费学习笔记（深入）”；
初始化开销怎么排除？b.ResetTimer()不是可选的
所有预热、构造输入、分配缓存等操作，必须放在循环外，并在循环前调用b.ResetTimer()，否则会被计入耗时：
func BenchmarkStringJoin(b *testing.B) {
parts := []string{"a", "b", "c"} // ✅ 初始化放循环外
b.ResetTimer() // ✅ 关键！重置计时起点
for i := 0; i < b.N; i++ {
_ = strings.Join(parts, "-") // ✅ 被测操作在此
}
}
漏掉b.ResetTimer()，哪怕只是多分配一个切片，都可能让ns/op虚高20%以上——尤其在小函数上，这点开销占比极大。
真正难的不是写对语法，而是在循环里藏住副作用、避开编译器优化、控制GC干扰。比如返回值不接_，可能被优化掉；用rand生成数据没复位种子，每次b.N迭代实际跑的是不同输入——这些细节，比记住规则更影响结果可信度。
