标准库 errors 和 fmt.Errorf 配合 %w 已覆盖 90% 场景；errors.Is 和 errors.As 在 Go 1.13+ 中支持错误链与类型提取，日志系统可补全调用栈；仅当需结构化字段、成熟分类体系且依赖反射策略或兼容旧 Go 时才考虑第三方库。
大多数 Go 项目不需要第三方错误库——标准库的 errors 和 fmt.Errorf 配合 %w 已覆盖 90% 的错误处理需求；引入第三方库（如 github.com/pkg/errors 或 github.com/cockroachdb/errors）只在特定场景下带来真实收益，且常伴随维护成本和生态割裂风险。
什么时候 errors.Is 和 errors.As 就够用了
Go 1.13+ 的标准库已原生支持错误链、类型断言和语义比较：
-
errors.Is(err, io.EOF)可穿透多层%w判断底层是否为某个哨兵错误 -
errors.As(err, &target)能安全提取包装的错误类型（比如自定义结构体） - 调用栈信息虽不默认携带，但多数服务日志系统（如 Zap、Zerolog）会在记录时自动补全
runtime.Caller - HTTP 错误码映射、gRPC 状态码转换等常见场景，靠
switch+errors.Is即可清晰分发
哪些场景真值得考虑第三方错误库
仅当同时满足以下条件时才建议评估：
- 需要在错误中嵌入结构化字段（如
request_id、trace_id），且要求这些字段能被中间件统一提取、注入到日志或监控中 - 团队已有成熟错误分类体系（如按领域划分
ValidationError、ExternalServiceError），并依赖运行时反射或接口方法做策略分发 - 必须兼容旧版 Go（github.com/pkg/errors 的
Wrap和Cause是折中选择（但注意它已被作者标记为“unmaintained”） - 使用 CockroachDB 生态，其
github.com/cockroachdb/errors提供了与内部 SQL 执行器深度集成的错误分类和重试逻辑
容易被忽略的代价
第三方错误库不是零成本插件：
JTBC网站内容管理系统5.0.3.1
下载
JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也
立即学习“go语言免费学习笔记（深入）”；
- 不同库的包装方式不兼容：用
pkg/errors.Wrap包装的错误，errors.Is可能失效（因未实现Unwrap()或实现不一致） - 调试时
fmt.Printf("%+v", err)输出格式混乱，有的打印完整栈，有的只打一层，干扰问题定位 - 静态分析工具（如
errcheck、go vet）对非标准错误构造函数支持有限，可能漏报未处理错误 - 跨团队协作时，新人需额外学习某库的惯用法，而非直接理解 Go 原生错误模型
func handleUser(req *http.Request) error {
id := req.URL.Query().Get("id")
if id == "" {
return errors.New("missing user id") // 标准库足够
}
u, err := db.GetUser(ctx, id)
if err != nil {
return fmt.Errorf("failed to get user %s: %w", id, err) // %w 表达因果，标准库原生支持
}
return nil
}
真正关键的不是“用不用第三方库”，而是统一错误构造方式、明确错误传播边界、以及确保日志和监控能拿到足够上下文——这些靠约定和工具链就能做到，不依赖特定库。
