17370845950

errors.Unwrap 仅手动解一层包装，不适用于理解错误链；真正用于判断和定位错误链的是 errors.Is（自动遍历匹配错误值）和 errors.As（安全提取嵌套错误类型）。

errors.Unwrap 不是用来“理解错误链”的工具，而是用来手动解一层包装的函数；真正帮你理解、判断和定位错误链的，是 errors.Is 和 errors.As。

为什么不能只靠 errors.Unwrap 来处理错误链

它只解一层，且返回 nil 时你无法知道是到底没包装、还是包装了但底层为 nil。更重要的是：它不关心语义，只做机械解包。

• 你得自己写循环才能拿到最底层错误，容易漏判或无限循环（比如自定义 Unwrap 返回自身）
• 无法判断是否“等于”某个已知错误值（比如 os.ErrPermission），因为 == 比较的是接口地址，不是内容
• 无法提取嵌套的自定义错误类型（如 *os.PathError），类型断言 err.(*os.PathError) 在被 %w 包装后直接失败

errors.Is 才是你该优先用的“相等判断”工具

它自动遍历整个错误链，只要某一层匹配目标错误值，就返回 true —— 这才是生产环境里判断“是不是权限问题”“是不是文件不存在”的正确姿势。

var ErrPermission = errors.New("permission denied")

func openConfig() error {
    f, err := os.Open("/etc/app.conf")
    if err != nil {
        return fmt.Errorf("failed to open config: %w", err)
    }
    defer f.Close()
    return nil
}

err := openConfig()
if errors.Is(err, os.ErrPermission) { // ✅ 正确：穿透包装判断
    log.Println("no permission to read config")
}
// 千万别写 if err == os.ErrPermission ❌（永远 false）

errors.As 是提取具体错误类型的唯一可靠方式

当你需要访问错误里的字段（比如路径、系统调用号、HTTP 状态码），必须用它。它会顺着错误链往下找，直到找到第一个能转换成目标类型的错误。

• 适用于所有实现了 Unwrap() error 的错误（包括 fmt.Errorf(... %w ...) 创建的）
• 传入的是指针地址（&target），不是值；否则无法赋值
• 如果错误链里有多个同类型错误，它只返回第一个匹配的

var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Printf("failed on path: %s", pathErr.Path) // ✅ 安全取到路径
}

手动调用 errors.Unwrap 的合理场景其实很少

仅在两种情况下值得考虑：

• 你需要打印/记录完整的错误展开路径（比如调试时逐层输出 err.Error() + errors.Unwrap(err)）
• 你在写一个通用错误分析工具，且明确知道错误链深度可控、无环（比如日志中间件中做简单分类）

除此之外，99% 的业务逻辑都应该用 errors.Is 或 errors.As 替代手写循环解包——它们更安全、更简洁、也更符合 Go 1.13+ 的设计意图。别让 Unwrap 成为你错误处理的默认起点。