Go 中的 wrapped error 是实现了 Unwrap() 方法、支持 errors.Unwrap() 返回非 nil 的错误值，需用 %w 包装、errors.Is() 判断根本原因、errors.As() 提取具体类型。
识别 Go 中的 wrapped error，关键不是“猜”，而是用对工具、看准行为——它本质上是一个带 Unwrap() 方法的错误值，能一层层剥开上下文，直到最底层原因。
看是否支持 errors.Unwrap()
这是最直接的判断方式。只要一个 error 值调用 errors.Unwrap(err) 返回非 nil，就说明它是被包装过的：
-
fmt.Errorf("加载配置失败: %w", io.ErrUnexpectedEOF)→ 支持 unwrap -
errors.New("找不到用户")→ 不支持 unwrap，errors.Unwrap()返回 nil - 自定义错误类型若实现了
Unwrap() error方法，也属于 wrapped error
用 errors.Is() 快速定位根本错误
不用手动层层 unwrap，errors.Is() 会自动遍历整个错误链，检查是否包含某个哨兵错误（比如 os.ErrNotExist 或自定义的 ErrTimeout）：
-
if errors.Is(err, os.ErrNotExist) { ... }—— 即使 err 是fmt.Errorf("读取缓存失败: %w", os.ErrNotExist)，也能命中 - 它比
err == os.ErrNotExist更安全，也比自己写循环调用Unwrap()简洁可靠
用 errors.As() 提取具体错误类型
当你需要拿到嵌套里的某个自定义错误实例（比如 *MyDBError 或 *ParseError），用 errors.As()：
var dbErr *MyDBErrorif errors.As(err, &dbErr) { log.Printf("DB code: %d", dbErr.Code) }- 它会顺着错误链查找第一个匹配类型的错误，并赋值给目标变量
注意包装时必须用 %w，不能用 %v
这是最容易踩的坑：只有 %w 才让错误具备可 unwrap 能力；%v 只是字符串拼接，彻底丢失原始错误：
- ✅ 正确：
fmt.Errorf("解析 JSON 失败: %w", json.SyntaxError) - ❌ 错误：
fmt.Errorf("解析 JSON 失败: %v", json.SyntaxError)→ 后续errors.Is()和Unwrap()全失效 - 编译器不会报错，但调试时会发现“错误消失了”——其实只是被抹掉了
基本上就这些。wrapped error 不复杂，但容易忽略 %w 和 Is/As 的配合使用。日常开发中，只要坚持用 %w 包装、用 Is 判断、用 As 提取，错误链就能真正帮你定位到第一现场。
