errors.Unwrap 不能一次性拿到最底层错误，因为它每次只解一层且非递归；需手动循环调用直至返回 nil，并加层数限制防环。
errors.Unwrap 为什么不能一次性拿到最底层错误
errors.Unwrap 每次只解一层，不是递归函数。它返回 nil 表示当前错误没有包装（即可能是原始错误），但你得自己判断、循环、再调用——Go 标准库故意没提供 errors.Cause 那种“直达根因”的函数，因为“原始错误”的定义本身有歧义：是第一个 fmt.Errorf？还是最后一个 errors.WithStack？还是非 fmt.Errorf 的 error 实例？
常见错误现象：errors.Unwrap(err) 返回 nil，你以为到底了，结果其实是 err 本身已经是个原始 *os.PathError 或 *net.OpError，根本没被 fmt.Errorf 包过，所以 Unwrap 天然不生效。
- 必须手动循环调用
errors.Unwrap，直到返回nil - 注意：有些自定义错误类型可能实现
Unwrap() error方法但返回自身（形成环），要加计数限制防死循环（比如最多 10 层） - 别依赖
Unwrap判断错误类型；该用errors.Is或errors.As的地方就用它们
手写递归 Unwrap 的安全写法
标准库没给，就得自己写个带防护的版本。核心是：检查是否可 unwrap → 解包 → 判断是否终止 → 继续或退出。
下面这个函数能安全走到最深一层，同时避免无限循环：
立即学习“go语言免费学习笔记（深入）”；
func rootError(err error) error {
for i := 0; i < 10 && err != nil; i++ {
unwrapped := errors.Unwrap(err)
if unwrapped == nil {
return err
}
err = unwrapped
}
return err
}
- 上限 10 层是经验值，够覆盖绝大多数日志/中间件链路（
http.Handler→service.Do→db.Query） - 循环中直接用
errors.Unwrap(err)，不要用err.Unwrap()—— 后者可能 panic（如果err是nil或未实现接口） - 返回值不一定是“原始错误”，而是“最后一层可 unwrap 的错误”；真要拿原始 error，还得结合
errors.As做类型断言
errors.Is 和 errors.As 才是日常该用的工具
90% 的场景根本不需要手动递归 Unwrap。比如你想知道是不是 os.ErrNotExist，直接 errors.Is(err, os.ErrNotExist) 就行；想提取 *os.PathError，用 errors.As(err, &pathErr)。
它们内部已经做了完整的 unwrap 链遍历，比你自己写的更健壮（支持多级嵌套、跳过中间非 error 接口类型等）。
-
errors.Is本质是逐层Unwrap+==比较，支持自定义Is(error) bool方法 -
errors.As会尝试对每一层调用As(interface{}) bool，或做类型断言；比手动rootError后再if x, ok := err.(*os.PathError)更可靠 - 只有调试、日志聚合、错误分类统计这类需要“看一眼整个链”的场景，才值得手动展开 unwrap
第三方库如 github.com/pkg/errors 已停更，别再引入
github.com/pkg/errors 的 errors.Cause 曾是主流方案，但它在 Go 1.13+ 原生错误链支持后就停止维护了。现在混用会导致行为不一致：它的 Cause 不识别标准库的 Unwrap 方法，而标准库的 Is/As 也不认它的 causer 接口。
- 新项目一律用标准库
errors+fmt.Errorf("...: %w", err) - 存量项目迁移时，重点检查
pkg/errors.Cause调用点，替换成errors.Is或带防护的rootError - 特别注意：
fmt.Errorf("%v", err)会切断错误链，必须用%w动词才能保留Unwrap能力
最常被忽略的是：即使写了 %w，如果上游错误本身没实现 Unwrap（比如某些 SDK 返回的 struct error 没配方法），整条链还是会在那里断掉——这时候得看文档，或加一层包装再抛出。
