errors.unwrap只解一层，因它是单步操作而非递归函数；仅检查当前error是否实现unwrap()方法，有则返回其结果，否则返回nil，不检测环、不遍历下层、不判断是否“到底”。
errors.Unwrap 为什么只解一层就返回
errors.Unwrap 是单步操作，不是递归函数。它只检查当前 error 是否实现了 Unwrap() error 方法，有则返回其结果，否则返回 nil。它不检测环、不遍历下一层、不判断是否“到底”，这是接口契约，不是缺陷。
常见错误现象：errors.Unwrap(err) 返回 nil，你以为链断了，其实只是当前错误没实现 Unwrap()（比如 errors.New("xxx") 或字符串拼接错误）；或者你误以为调一次就能拿到最底层，结果只剥掉最外一层。
- 用
fmt.Errorf("msg: %w", inner)构造的错误才支持Unwrap - 用
+、fmt.Sprintf、%v拼接的错误不实现Unwrap()，errors.Unwrap必然返回nil - 自定义错误类型若要参与标准链逻辑，必须导出字段并让
Unwrap()方法原样返回那个被包裹的error实例，不能返回新构造的错误
手动循环调用 errors.Unwrap 的安全写法
真要逐层展开直到终点，得自己写循环，但必须加两道防护：空值判别和层数上限。否则可能 panic（虽然 errors.Unwrap(nil) 不 panic，但后续逻辑会错），或陷入死循环（比如自引用错误）。
下面这个函数是生产可用的最小安全实现：
func rootError(err error) error {
for i := 0; i
- 始终用
errors.Unwrap(err)，不要用err.Unwrap()—— 后者在err是nil或未实现接口时会 panic - 上限设为 10 层是经验值，覆盖 HTTP handler → service → db 等典型链路，再深大概率是设计问题
- 返回值不一定是“原始错误”，而是“最后一层可 unwrap 的错误”；要提取具体类型，还得配合
errors.As
errors.Is 和 errors.As 才是递归拆箱的实际落地方式
90% 场景根本不需要手写循环。你要判断错误链里有没有 os.ErrNotExist？直接 errors.Is(err, os.ErrNotExist)。你要提取某一层的 *os.PathError？用 errors.As(err, &pe)。
它们内部已做了完整、带环检测的递归遍历，能正确处理：
- 中间某层用了
fmt.Errorf("%v", inner)（没用%w）导致链断裂？Is/As会跳过该层继续往下 - 自定义错误实现了
Is(error) bool或As(interface{}) bool？它们会优先调用这些方法 - 传入
nil？安全，不 panic
手动调用 errors.Unwrap 反而绕过了这些健壮逻辑，还容易漏掉多层嵌套或误判终止条件。
哪些错误根本无法被 Unwrap 拆开
errors.Unwrap 只对显式支持包装的错误有效。以下情况调用它必然返回 nil：
-
errors.New("xxx")创建的错误 —— 类型是*errors.errorString，没实现Unwrap() - 用
fmt.Sprintf、+拼接的字符串错误 —— 同样是*errors.errorString，无Unwrap方法 - 自定义错误类型没实现
Unwrap() error，或实现了但返回了硬编码错误（如return io.ErrUnexpectedEOF）而非真实包裹对象
这类错误一旦混入链中，就会成为“断点”。errors.Is 和 errors.As 遇到它们会跳过，但手动 Unwrap 循环会在这里提前终止——你得意识到：返回 nil 不代表“到底了”，只代表“这一层不支持展开”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
