17370845950

Go 中 error 类型本身性能开销极小，真正影响性能的是错误的创建方式：fmt.Errorf 格式化、带栈追踪、热路径频繁构造均会显著增加开销，errors.New 则最轻量。

Go 中 error 类型本身几乎不带来性能开销

Go 的 error 是一个接口类型，底层通常只是指针或小结构体（如 errors.Err 是 *errors.errorString）。创建一个基础错误（比如 errors.New("xxx")）的开销极小，分配量少、无栈追踪、不触发 GC 压力。真正影响性能的不是 error 类型，而是你**怎么生成它**。

常见高开销场景包括：

• fmt.Errorf 中带格式化字符串（尤其是含变量拼接），会触发内存分配和字符串构建
• 使用 errors.WithStack 或 github.com/pkg/errors 等带栈信息的包，每次调用都调用 runtime.Caller，成本显著
• 在热路径（如循环内部、高频 HTTP handler）中反复构造新错误，即使轻量也会累积分配压力

对比 errors.New 和 fmt.Errorf 的实际开销

两者语义不同：errors.New 返回静态字符串错误；fmt.Errorf 支持格式化，但默认启用栈捕获（Go 1.13+ 的 fmt.Errorf 不自动加栈，但若用 %w 包裹则可能触发包装逻辑）。

基准测试显示，在无格式化参数时，fmt.Errorf("xxx") 比 errors.New("xxx") 慢约 2–3 倍，主因是 fmt 的通用解析逻辑；一旦加入变量（如 fmt.Errorf("id=%d", id)），分配和耗时会进一步上升。

func BenchmarkErrorsNew(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = errors.New("not found")
	}
}

func BenchmarkFmtErrorfNoArg(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = fmt.Errorf("not found")
	}
}

func BenchmarkFmtErrorfWithArg(b *testing.B) {
	id := 123
	for i := 0; i < b.N; i++ {
		_ = fmt.Errorf("id=%d", id)
	}
}

错误包装（%w）是否拖慢性能？

Go 1.13 引入的错误包装机制本身开销很低：它只是把一个 error 存进另一个 struct 字段（如 wrapError），没有自动收集栈。但要注意：

• 如果包装链过长（如多层 fmt.Errorf("%w", err)），errors.Is / errors.As 需要遍历链表，O(n) 时间复杂度
• 某些日志库（如 log/slog 默认）在打印 error 时会调用 fmt.Sprint，进而触发 Error() 方法——若你的包装错误重写了该方法并做了复杂操作（如拼接上下文、查表），就会成为瓶颈
• 避免在热路径做 errors.Unwrap 循环或深度 errors.Is 判断

高频错误场景下的实用建议

真正影响服务吞吐的，往往不是“有没有 error”，而是“错误是否被频繁创建 + 是否被无谓传播”。几个可立即落地的点：

• 对固定错误（如 "EOF"、"invalid input"），直接定义为包级变量：var ErrInvalidInput = errors.New("invalid input")，避免重复分配
• HTTP handler 中不要为每个失败请求都 fmt.Errorf("failed to process %s: %v", req.ID, err)；优先复用错误变量，或只在 debug 日志里补上下文
• 数据库查询失败时，慎用 fmt.Errorf("query failed: %w", err) 包装；多数情况直接返回原始 err 更高效，业务层再按需分类
• 用 go tool trace 或 pprof 实际观察 runtime.mallocgc 和 errors.New 调用频次，比凭经验猜测更可靠

错误处理的设计权衡不在“要不要用 error”，而在“什么时候该提前拦截、什么时候该复用、什么时候根本不必构造新 error”。性能损耗从来不出现在 if err != nil 这一行，而出现在你让它发生的每一处构造和包装里。