17370845950

Go benchmark中禁用log.Fatal或panic，应使用b.Error()或b.Fatal()报告错误；setup阶段错误用b.Fatal()提前退出，循环内错误用b.Error()记录后continue，避免中断整个测试流程。

Go benchmark 中不能用 log.Fatal 或 panic 捕获错误

Go 的 testing.B 函数运行在受控环境中，一旦触发 panic 或调用 log.Fatal，整个基准测试会立即终止，且不报告任何结果（甚至不显示 BenchmarkXXX 已执行）。这不是“捕获错误”，而是让测试崩溃。

• 正确做法是：所有错误必须显式检查并用 b.Error() 或 b.Fatal() 报告（仅限失败时）
• b.Fatal() 会标记该次 benchmark 失败并停止当前函数，但不会中断整个 go test -bench 流程
• 若错误不影响性能逻辑（例如初始化失败），应在 BenchmarkXxx 开头处理，避免进入 b.ResetTimer() 后才出错

如何在 testing.B 中安全调用可能出错的函数

典型场景是被测函数返回 (result, error)，比如 json.Marshal、http.Post 模拟或数据库查询。直接忽略错误会导致结果不可信；用 if err != nil { panic(err) } 会让 benchmark 崩溃。

• 把错误检查放在 b.ResetTimer() 之前 —— 如果 setup 阶段就失败，说明测试环境有问题，应提前退出
• 如果错误发生在循环体内（即每次迭代都可能出错），必须判断并跳过本次迭代，或用 b.StopTimer() + b.StartTimer() 隔离错误处理开销
• 不要在循环中调用 b.Fatal()，它会中断整个 benchmark 迭代；改用 b.Error() 记录后 continue

func BenchmarkJSONMarshal(b *testing.B) {
	data := map[string]int{"x": 1, "y": 2}
	// setup 阶段检查
	if _, err := json.Marshal(data); err != nil {
		b.Fatal("setup failed:", err)
	}

	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		out, err := json.Marshal(data)
		if err != nil {
			b.Error("marshal failed at iteration", i, ":", err)
			continue // 跳过本次，不计入计时
		}
		_ = out
	}
}

go test -bench 不显示错误详情？检查是否漏了 b.Error() 调用

默认情况下，benchmark 只输出耗时和内存分配数据，b.Error() 的内容不会自动打印，除非加上 -benchmem -v 参数。很多开发者以为“没报错”其实是错误被静默吞掉了。

• 运行 benchmark 时务必加 -v： go test -bench=. -benchmem -v
• b.Error() 和 b.Fatal() 的输出只在失败时显示；如果 benchmark 成功完成（哪怕中间有 b.Error()），也不会中断，但错误信息仍会出现在终端
• 注意区分：b.Error() 是记录错误但继续跑完所有 b.N 次；b.Fatal() 是立刻终止当前 benchmark 函数

错误处理本身会影响 benchmark 结果，需要隔离测量

真实代码里错误分支往往比正常路径慢得多（比如网络超时、磁盘 I/O 失败重试），直接把错误处理混进主循环会严重污染 ns/op 数据。你测的不是“成功路径性能”，而是“平均错误混合路径性能”。

• 如需单独测错误路径性能，应写独立 benchmark，用构造的错误输入触发（例如传入非法 JSON 字节流给 json.Unmarshal）
• 避免在主 benchmark 循环中做条件分支判断错误类型；错误应是异常情况，不该出现在热路径
• 如果业务逻辑强制要求每轮都 check error（比如 retry loop），那 benchmark 就该反映这个真实开销 —— 但要确保错误率可控（例如固定 1%），否则结果抖动太大

实际中最容易被忽略的是：**benchmark 的 b.N 是动态调整的，一旦某次迭代因错误导致耗时剧增，整个 b.N 可能被大幅下调，最终你看到的 ns/op 其实来自极少量样本，且无法复现**。务必先用小规模 -benchtime=10ms 验证逻辑稳定再拉长测试时间。