errors.Unwrap只解一层是设计使然，因Go错误链表达包装关系而非继承树，需手动循环调用并判空；errors.Is和As则内置环检测与递归遍历，更安全高效。
errors.Unwrap 为什么只解一层就停了
errors.Unwrap 的设计就是单步解包，它不递归，也不自动遍历整个错误链。这是有意为之——Go 错误链的语义是“包装关系”，不是“继承树”，Unwrap 只负责暴露直接被包装的那个错误，剩下的交给你自己决定是否继续解、怎么解、要不要加条件过滤。
常见错误现象：errors.Unwrap(err) 返回 nil，你以为链断了，其实只是当前错误没实现 Unwrap() error 方法；或者你连续调用两次 Unwrap，却忘了第二次要作用在上一次结果上，写成 errors.Unwrap(err) 两次，等于白调。
- 必须手动循环调用：
for err != nil { ... err = errors.Unwrap(err) } - 注意空值判断：每次
Unwrap后都要检查返回值是否为nil，否则 panic -
fmt.Errorf("...: %w", inner)包装的错误才支持Unwrap；用+拼接或sprintf构造的字符串错误不支持
用 errors.Is 判断底层错误类型更安全
手动递归 Unwrap 容易漏掉中间某层，也容易陷入无限循环（比如自引用错误）。而 errors.Is 内部已经做了带环检测和逐层 Unwrap，适合判断“这个错误链里有没有某个特定错误”。
使用场景：HTTP handler 中想统一拦截 os.ErrNotExist 做 404，不管它被 fmt.Errorf 包了多少层。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is(err, os.ErrNotExist)✅ 自动遍历整条链 -
err == os.ErrNotExist❌ 只比对顶层，几乎总失败 - 自定义错误类型也要实现
Is(target error) bool才能被errors.Is正确识别
errors.As 怎么提取中间某层的具体错误值
当你需要拿到错误链中某个具体类型的实例（比如 *os.PathError），而不是只判断是否存在，就得用 errors.As。它会从顶层开始逐层 Unwrap，对每一层调用 As 尝试类型断言。
参数差异：第二个参数必须是指针（*os.PathError），不是值类型（os.PathError），否则返回 false。
- 正确：
var pe *os.PathError; if errors.As(err, &pe) { ... } - 错误：
var pe os.PathError; if errors.As(err, &pe) { ... }—— 类型不匹配，永远失败 - 如果错误链中有多个匹配项，
As只返回第一个找到的，不会继续往后找
递归解包时如何避免死循环和性能陷阱
错误链理论上可能成环（虽然少见），比如 A.Wrap(B), B.Wrap(A)。直接 while 循环 Unwrap 会卡死。标准库的 errors.Is 和 As 都内置了环检测，但自己手写递归时得防着点。
性能影响：每层 Unwrap 是一次接口方法调用，开销小，但若错误链过深（>50 层），且你在 hot path 上反复解包，就会有可测量的延迟。
- 加深度限制：
for i := 0; i - 避免在循环里重复构造新错误（比如每次
fmt.Errorf("%w", err)），这会让链无限变长 - 日志打印错误时用
%+v而不是%v，能自动展开整个链，比手动解包更省事
真正难的不是怎么解包，而是想清楚哪一层的信息你真的需要——多数时候，errors.Is 和 errors.As 已经覆盖了 95% 的需求；手写递归解包，往往是因为没看清错误链的结构，或者过早优化了。
