errors.Unwrap每次只解一层包装错误，不递归；需手动循环调用才能获取最内层原始错误，且可能返回nil或另一包装错误。
errors.Unwrap 能否逐层解开所有嵌套错误
errors.Unwrap 每次只解一层，返回最内层的直接包装错误（即调用 fmt.Errorf("...: %w", err) 中的 %w 所指向的那个），不递归。它可能返回 nil（比如底层错误没实现 Unwrap() error 方法），也可能返回另一个包装错误——是否继续解开，得由你手动循环判断。
常见误用是以为调用一次就能拿到根因：
err := fmt.Errorf("service failed: %w", fmt.Errorf("db timeout: %w", io.EOF))
fmt.Println(errors.Unwrap(err)) // 输出: db timeout: io.EOF（不是 io.EOF！）
正确做法是写个循环或递归函数提取最底层原始错误：
- 用
for err != nil { next := errors.Unwrap(err); if next == nil { break }; err = next } - 注意：某些中间错误可能同时实现了
Unwrap()和自定义错误类型（如*os.PathError），此时仅靠Unwrap会跳过类型信息，需配合errors.As
errors.As 为什么有时匹配不到底层具体错误类型
errors.As 不是“穿透所有包装找类型”，而是按错误链顺序逐层调用 errors.Unwrap，对每一层结果执行 errors.As 判断——但关键限制是：它只检查该层错误本身是否可转型为目标类型，不自动解包再试。也就是说，如果目标类型藏在第二层，而第一层是 *fmt.wrapError（不实现你的目标接口），As 就会失败。
立即学习“go语言免费学习笔记（深入）”；
典型场景：
err := fmt.Errorf("http call failed: %w", &url.Error{Err: io.EOF})
var uerr *url.Error
if errors.As(err, &uerr) { // ✅ 成功，因为 wrapError.Unwrap() 返回 *url.Error，As 对它做类型断言
log.Println(uerr.Err) // io.EOF
}
但如果包装了两层：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
err := fmt.Errorf("retry: %w", fmt.Errorf("http: %w", &url.Error{Err: io.EOF}))
var uerr *url.Error
if errors.As(err, &uerr) { // ❌ 失败！第一层 unwrap 是 *fmt.wrapError，无法转成 *url.Error
// ...
}
解决办法：确保每层都支持 As（比如自定义错误类型显式实现 As(interface{}) bool），或手动展开后逐层 As。
自定义错误类型如何正确支持 Unwrap 和 As
要让自己的错误参与标准错误链解析，必须满足两个条件：
- 实现
Unwrap() error方法，返回被包装的错误（可以是nil） - 实现
As(interface{}) bool方法，允许外部用errors.As提取本类型实例
示例（带上下文的数据库错误）：
type DBError struct {
Op string
Err error
}
func (e *DBError) Error() string { return fmt.Sprintf("db.%s: %v", e.Op, e.Err) }
func (e *DBError) Unwrap() error { return e.Err }
func (e *DBError) As(target interface{}) bool {
if p, ok := target.(*DBError); ok {
*p = *e
return true
}
return errors.As(e.Err, target) // 向下委托
}
注意：As 方法里一定要向下委托给 e.Err，否则嵌套时会断链；Unwrap 返回 nil 表示无包装，不要 panic 或返回自身。
使用 errors.Is 和 errors.As 时容易忽略的边界情况
errors.Is 判断是否等于某个特定错误值（如 io.EOF、sql.ErrNoRows），它会沿 Unwrap 链逐层比对——但前提是目标错误本身是可比较的（不能是 map/slice/func）。而 errors.As 的陷阱更隐蔽：
- 传入的
target必须是指针（&v），否则As直接返回false，且不报错 - 如果错误链中某层
Unwrap()返回非nil但不是错误（比如 panic 时的非error值），As会跳过该层，不崩溃但可能漏匹配 -
As不处理接口类型断言（如io.Reader），只认具体指针类型或接口的实现者，且要求目标接口已导出
最常被忽略的一点：fmt.Errorf("msg: %w", err) 中的 %w 如果传入 nil，整个错误变成 nil（不是包装了 nil），此时 Unwrap() 返回 nil，As 也无从谈起——务必检查原始 err 是否为 nil 再包装。
