Golangerrors.New与Wrap用法解析

本篇文章向大家介绍《Golang errors.New与Wrap使用详解》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

Go标准库errors.New仅创建含静态字符串的error，不带堆栈且不可展开；errors.Wrap来自已归档的github.com/pkg/errors，标准库用fmt.Errorf(...%w)替代，%w须在末尾且仅一次。

Go 的 errors 包里没有 errors.New 和 errors.Wrap 同时存在 —— errors.Wrap 来自第三方库 github.com/pkg/errors，而标准库 errors（Go 1.13+）只提供 errors.New、errors.Unwrap、errors.Is、errors.As 等基础能力。

Go 标准库 errors.New 是什么，怎么用

这是最轻量的错误创建方式，返回一个只含静态字符串的 error 实例，不带堆栈、不可展开、不可比较类型。

• 适合简单上下文，比如参数校验失败：errors.New("invalid ID")
• 不能携带额外字段或原始错误，也不支持嵌套（即无法表示“因为 A 失败，导致 B 失败”）
• Go 1.13+ 后它仍完全可用，但若需链式错误追踪，必须配合 fmt.Errorf + %w 动词

err := errors.New("database connection failed")
fmt.Println(err.Error()) // "database connection failed"

errors.Wrap 是哪个包的，为什么标准库没有

errors.Wrap 属于已归档的 github.com/pkg/errors 库，它在 Go 1.13 前是事实标准，用于添加上下文和捕获调用栈。标准库没采纳它的设计，而是用更轻量的 fmt.Errorf(... %w) 替代。

• pkg/errors.Wrap(err, "read config") 会把原错误 err 包装，并记录当前调用位置的栈帧
• 标准库不提供等价函数，因为 Go 团队认为显式使用 %w 更可控，且避免隐式栈采集开销
• 如果你项目还在用 pkg/errors，注意它已不再维护；新项目应优先用标准库方案

标准库替代 errors.Wrap 的正确写法（Go 1.13+）

用 fmt.Errorf + %w 动词实现语义等价的包装，同时支持 errors.Unwrap、errors.Is 等标准行为。

• %w 必须是最后一个参数，且只能出现一次；它标记被包装的底层错误
• 包装后错误可递归展开：errors.Unwrap(wrappedErr) 返回原始错误
• 判断是否由某类错误引起：errors.Is(wrappedErr, fs.ErrNotExist)
• 提取具体错误类型：errors.As(wrappedErr, &pathErr)

err := os.Open("config.json")
if err != nil {
    return fmt.Errorf("failed to load config: %w", err) // ← 这就是 Wrap 的标准库写法
}

容易踩的坑：%w 写错位置或误用 %v

常见错误不是语法报错，而是让错误链断裂或丢失关键信息。

• 写成 fmt.Errorf("failed: %v", err) → 原错误被转成字符串，errors.Unwrap 返回 nil，errors.Is 失效
• 写成 fmt.Errorf("%w: failed", err) → %w 不在末尾，编译报错
• 多次包装同一错误却没留心栈深度：过度包装会让 errors.Unwrap 需要调用多次，但逻辑上只需一层上下文
• 在 defer 中用 %w 包装可能捕获到已关闭资源的错误，需确认原始错误是否还有效

真正需要错误链时，别纠结 Wrap 名字，盯住 %w 是否存在、是否在末尾、原始错误是否非 nil —— 这三点决定了你的错误能否被下游正确诊断和恢复。

好了，本文到此结束，带大家了解了《Golangerrors.New与Wrap用法解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！