go 1.13+ 的 errors.is 和 errors.as 对嵌套错误失效，是因为它们依赖 unwrap() 方法逐层解包，而自定义错误类型未实现或错误实现该方法；默认 fmt.errorf("...: %w", err) 自动提供 unwrap()，但结构体错误必须手动实现，且需安全返回可透出的下层错误，避免 nil panic 或无限递归。
Go 1.13+ 的 errors.Is 和 errors.As 为什么对嵌套错误失效？
因为它们依赖 Unwrap() 方法逐层解包，而你没实现它，或者实现得不正确。默认的 fmt.Errorf("...: %w", err) 确实会自动带 Unwrap()，但一旦你自定义错误类型（比如带字段的结构体），Go 就不会帮你生成——必须手动实现。
常见错误现象：errors.Is(err, myCustomErr) 返回 false，哪怕 err 明明是用 %w 包装过的；errors.As(err, &target) 也失败。
- 只有实现了
Unwrap() error方法的类型，才能被标准库错误处理链识别 - 返回
nil表示“到底了”，不能再解包；返回非nil错误才继续递归 - 如果嵌套多层但某一层的
Unwrap()返回nil（比如忘了写 return），后续层就永远不可达
自定义错误类型怎么写 Unwrap() 才安全？
核心原则：只暴露你「有意传递」的下层错误，不暴露内部临时变量或 nil 指针。别为了“看起来完整”而硬塞一个可能 panic 的 Unwrap()。
典型场景：封装数据库操作错误，想保留原始 *pq.Error 以便调用方做 SQL 状态码判断。
立即学习“go语言免费学习笔记（深入）”；
type DBError struct {
Op string
Err error // 这个才是要 unwrap 的
}
func (e *DBError) Error() string {
return fmt.Sprintf("db %s failed: %v", e.Op, e.Err)
}
func (e *DBError) Unwrap() error {
return e.Err // ✅ 直接返回字段，且该字段在构造时已确保非 nil（或允许为 nil）
}
- 不要在
Unwrap()里做逻辑判断、日志、或调用其他可能 panic 的方法 - 如果
Err字段可能为nil，直接返回它就行——errors.Is遇到nil会停止解包，这是符合预期的行为 - 避免返回新构造的错误（如
fmt.Errorf("wrap: %w", e.Err)），这会造成无限递归或内存泄漏
%w 和 %v 在错误包装时的区别有多大？
区别是「是否可解包」——%w 触发 Go 运行时注入 Unwrap() 方法，%v 只是字符串拼接，彻底断掉错误链。
使用场景：你想让调用方能用 errors.As(err, &pqErr) 拿到 PostgreSQL 原始错误，就必须用 %w；如果只是记录日志用，%v 更轻量、更可控。
-
fmt.Errorf("timeout: %w", io.ErrUnexpectedEOF)→ 可被errors.Is(..., io.ErrUnexpectedEOF)匹配 -
fmt.Errorf("timeout: %v", io.ErrUnexpectedEOF)→ 解包后得到nil，链在此中断 - 混用风险：同一错误链中既有
%w又有%v，会导致部分层级丢失，调试时查不到根因
为什么 Unwrap() 返回多个错误会出问题？
因为 Go 的 Unwrap() 接口定义是 func Unwrap() error，单返回值。试图返回多个（比如切片）不仅编译不过，还说明你混淆了「错误嵌套」和「错误聚合」。
真实需求往往是：一个操作失败伴随多个子错误（如批量上传中几个文件失败）。这时不该用 Unwrap()，而该用专用聚合类型（如 multierr 库），或自定义 Errors() []error 方法并配合显式遍历。
- 标准库所有错误处理函数（
Is/As/Unwrap）都只认单层Unwrap() - 强行用结构体字段存多个错误 + 实现
Unwrap()返回第一个，会掩盖其余错误，违反直觉 - 若真需多错误透传，接受方应主动调用你的自定义方法（如
e.Errors()），而不是依赖标准解包机制
Unwrap() 是否精准表达“这个错误里真正值得向上透出的因果”。漏掉一层，下游就断连；多塞一层，反而误导排查方向。 
