errors.As 是判断错误是否为特定类型的推荐方式，它能穿透 %w 包装正确匹配嵌套错误，需传入目标类型指针（如 &pathErr），返回 bool 并赋值；而 errors.Is 用于判断错误链中是否存在特定错误值（如 os.ErrNotExist），需实现 Is 方法。
如何用 errors.As 判断错误是否为特定类型
Go 1.13 引入的 errors.As 是最推荐的方式，它能正确处理嵌套错误（比如被 fmt.Errorf("...: %w", err) 包装过的错误），而传统类型断言 err.(*MyError) 在嵌套时会失败。
常见错误现象：明明错误底层是 *os.PathError，但 err.(*os.PathError) 返回 false —— 很可能因为上游用了 %w 包装。
- 必须传入指向目标类型的指针（如
&target），不是类型本身 - 返回
bool表示是否成功匹配，匹配后目标变量会被赋值 - 对自定义错误类型，只要实现了
error接口，就能被errors.As检测
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("文件路径错误: %s", pathErr.Path)
}
什么时候该用 errors.Is 而不是类型断言
errors.Is 用于判断错误链中是否存在某个**特定错误值**（比如 os.ErrNotExist），而不是类型。它和 errors.As 解决的是不同问题。
典型场景：你想知道一个 I/O 错误是不是“文件不存在”，而不是关心它是不是 *os.PathError —— 因为可能是 os.ErrNotExist 本身，也可能是被包装过的 *os.PathError，甚至第三方库返回的等价错误。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is(err, os.ErrNotExist)会逐层展开Unwrap()并比较值相等 - 不能用它来区分不同结构体类型（比如
*MyErrorvs*OtherError） - 自定义错误若想支持
errors.Is，需实现Is(target error) bool方法
if errors.Is(err, os.ErrNotExist) {
// 处理文件不存在逻辑
}
直接类型断言 err.(*MyError) 的适用边界
仅在你**完全确定错误未被包装**、且来自可信内部调用时可用。例如：你自己写的函数明确返回 &MyError{...}，且调用方没用 %w 再包装。
一旦涉及标准库、第三方包或任意中间层的错误包装，这种断言大概率失效。很多新手在这里卡住，反复检查类型名却忽略包装层级。
- 语法是
v, ok := err.(*MyError)，不是err.(*MyError)单独使用 - 如果
ok == false，v是 nil 指针，直接解引用会 panic - 无法穿透
fmt.Errorf("wrap: %w", err)或errors.Join等多错误结构
v, ok := err.(*MyError)
if ok {
// 安全使用 v
}
自定义错误类型要支持两种判断，得同时实现两个方法
如果你希望用户既能用 errors.As 断言类型，又能用 errors.Is 判断等价性，你的错误类型需要同时满足：
- 实现
error接口（必须） - 实现
Unwrap() error（让errors.Is和errors.As可以递归检查） - 实现
Is(target error) bool（控制errors.Is的匹配逻辑）
注意：不要在 Unwrap() 中无条件返回 nil，否则 errors.As 无法向下查找；也不要让 Is() 做过于宽松的匹配，否则会误判。
type MyError struct {
Msg string
Code int
Err error // 可选的底层错误
}
func (e *MyError) Error() string { return e.Msg }
func (e *MyError) Unwrap() error { return e.Err }
func (e *MyError) Is(target error) bool {
_, ok := target.(*MyError)
return ok && e.Code == target.(*MyError).Code
}
错误链的深度和包装方式直接影响判断结果，写判断逻辑前先用 fmt.Printf("%+v", err) 看清实际结构。 
