b.N 是 go 基准测试框架动态计算的执行次数配额，从 1 开始试跑并指数增长，使总耗时趋近 -benchtime（默认 1 秒），非手动设定常量。
什么是 b.N：它不是你写的循环次数，而是框架给你的“执行配额”
b.N 是 Go 基准测试框架自动计算并注入的整数值，表示当前轮次中被测代码**必须被执行的次数**。它不是常量，也不是你手动设的计数器——而是测试运行器根据实际耗时动态调整的结果，目标是让整个 BenchmarkXxx 函数总运行时间接近 -benchtime（默认 1 秒）。
- 框架从
b.N = 1开始试跑，若耗时远小于 1 秒，就指数级增大（如 1 → 2 → 5 → 10 → 20 → 50…），直到单轮总耗时稳定在目标区间内 - 你写的
for i := 0; i 只是“消费”这个配额，不是定义逻辑边界 - 如果在循环里偷偷改了输入数据（比如原地排序后没重置），后续迭代就测的是已排序数组——结果完全失真
为什么不能把准备逻辑写在 for 循环里
常见错误：在 for i := 0; i 内部生成随机数据、初始化切片、调用 rand.Seed() 等——这些操作会被重复 b.N 次，严重污染耗时和内存统计。
- 准备动作（如
generate(10000, -100, 100)）必须放在循环外，只做一次 - 若每次迭代需要独立数据（比如避免排序算法复用已排好序的输入），应在循环内克隆或重新生成，但要用
b.ResetTimer()排除准备开销 - 忘记
b.ResetTimer()会导致“数据生成时间”被计入性能指标，出现0.60 ns/op这类明显反直觉结果
func BenchmarkSortSelection(b *testing.B) { // ✅ 准备一次，不计入计时 data := generate(10000, -100, 100) b.ResetTimer() // ⚠️ 关键：从此刻开始计时 for i := 0; i < b.N; i++ { // ✅ 每次都用新副本，避免副作用 xs := append([]int(nil), data...) // 浅拷贝 SortSelection(xs) } } b.N 的实际取值永远由框架决定，别硬编码也别猜
有人试图用 if b.N > 1000 { b.N = 1000 } 或直接写死 for i := 0; i ——这会让基准测试失效。Go 不会识别你的硬编码，它仍按自己节奏跑多轮，并可能因耗时过短而报 too fast 或给出极低的 ns/op。
- 命令行参数才是控制入口：
go test -bench=. -benchtime=5s让框架以 5 秒为目标调整b.N -
-count=3可重复运行整套基准三次，用于观察波动性；-benchmem启用内存分配统计 - 编译器优化可能导致函数被内联或消除，记得把结果赋给全局变量（如
result = SortSelection(xs)），否则可能测出 “0 B/op” 和 “0 ns/op”
最容易被忽略的细节：随机数种子和数据复用
在 generate() 里反复调用 rand.Seed(time.Now().unixNano()) 不仅慢，还会因纳秒级时间戳在快速循环中重复，导致生成相同序列——排序算法实际总在测同一组“幸运数据”，性能数字毫无参考价值。
- 正确做法：在
init()或Benchmark函数开头设一次种子，或直接用固定种子保证可重现 - 更稳妥的做法：用
rand.New(rand.NewSource(123))创建局部伪随机器，避免全局rand包干扰 - 对排序类测试，建议每次迭代都用不同随机种子生成新数据，而不是复用一份——否则插入排序可能在第二轮就“撞上”几乎有序数组，性能虚高
真正难的不是写对 for i := 0; i ，而是分清哪部分该“只做一次”，哪部分该“每次重来”，以及怎么让框架相信你测的就是你想测的那块逻辑。