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 这一行，而出现在你让它发生的每一处构造和包装里。
