Go语言testing.B.N正确用法：两段基准测试代码差异解惑

两段代码的核心差异与无效原因 #

第一段基准测试代码无效的根本原因是：每次循环执行的工作负载不一致。

func BenchmarkFiboI(b *testing.B) {
 for i := 0; i < b.N; i++ {
 _ = fibo1(i)
 }
}

循环中传入fibo1的参数是递增的i，随着i变大，计算斐波那契数的耗时会显著增加，整个基准测试的总耗时和b.N不成线性关系。Go的基准测试框架需要每次循环执行完全相同的操作，才能通过调整b.N的大小，统计出稳定的单操作耗时。这种负载递增的测试，框架无法给出有效的性能数据。

而第二段代码每次循环都传入固定参数10，每次执行的计算量完全一致，框架能准确统计出单次调用fibo1(10)的耗时，因此是有效的基准测试：

func BenchmarkFiboIV(b *testing.B) {
 for i := 0; i < b.N; i++ {
 _ = fibo1(10)
 }
}

testing.B.N的正确使用原则 #

b.N是基准测试框架自动调整的循环次数变量，核心作用是通过多次重复相同操作，抵消单次执行的误差，得到可靠的性能数据。使用时必须遵守一个核心原则：

• 循环体内的操作必须无状态、负载固定，确保每次循环的耗时基本一致，这样框架才能通过总耗时 / b.N计算出准确的单操作性能（ops/sec）。

正确的基准测试写法 #

如果需要测试fibo1对不同参数的性能，应为每个参数单独编写基准测试函数：

// 测试fibo1(10)的性能
func BenchmarkFibo10(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = fibo1(10)
    }
}

// 测试fibo1(20)的性能
func BenchmarkFibo20(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = fibo1(20)
    }
}

如果确实需要测试参数递增的场景（比如模拟真实业务中数据量逐渐变大的情况），这种场景不属于标准基准测试的范畴，框架无法给出有效的单操作耗时。此时可以手动记录总耗时，但这种结果不适合用来和其他固定负载的测试做对比。

内容的提问来源于stack exchange，提问作者tens0r