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 成为你错误处理的默认起点。
