errors.Is 和 errors.As 是 Go 1.13+ 唯一推荐的错误判断方式，可穿透 %w 包装；Is 用于判断是否等于哨兵错误，As 用于提取底层错误结构体指针。
errors.Is 和 errors.As 是 Go 1.13+ 处理错误类型判断的**唯一推荐方式**，它们能穿透多层包装错误（比如用 %w 包裹的错误），而传统 == 或类型断言会失效。
什么时候用 errors.Is：判断是否等于某个哨兵错误
当你只想知道“是不是这个错”，比如文件不存在、EOF、自定义业务失败标识，就用 errors.Is。它比较的是错误值本身，不是类型。
- 必须使用包级变量定义的哨兵错误（
var ErrNotFound = errors.New("not found")），不能每次errors.New("not found")新建——否则Is永远返回false - 支持标准库已实现
Is()方法的错误，如os.ErrNotExist、io.EOF - 对
fmt.Errorf("read failed: %w", os.ErrNotExist)这类包装错误依然有效 - 性能比
errors.As略高，适合前置快速过滤
if errors.Is(err, os.ErrNotExist) {
log.Println("文件不存在，跳过处理")
}
什么时候用 errors.As：提取错误底层结构体或字段
当你需要访问错误内部字段（比如路径、错误码、原始消息）或调用其方法时，用 errors.As。它做的是类型匹配 + 赋值，目标变量必须是指针。
- 目标变量必须是指向具体类型的指针，例如
*os.PathError、*MyCustomError - 只取错误链中**第一个匹配的实例**（最内层被包装的那个），不会遍历全部
- 如果错误链里有多个同类型错误，
As不会合并或跳过，只取第一个找到的 - 不支持接口类型直接匹配（如
error），必须是具体类型或实现了该接口的结构体指针
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("操作 %s 失败于路径 %s: %v", pathErr.Op, pathErr.Path, pathErr.Err)
}
常见踩坑点：为什么你的判断总失败？
绝大多数错误类型判断失效，都源于这三类误用：
- 用
err == os.ErrNotExist—— 包装后外层错误不相等，直接返回false - 用
err.(*os.PathError)类型断言 —— 无法穿透%w包装，运行时 panic - 用
errors.New("permission denied")当作目标传给Is—— 每次新建对象地址不同，恒不相等；必须用包级变量 - 对自定义错误没实现
Unwrap() error方法 —— 导致Is和As无法向下递归，卡在第一层
组合使用才真正健壮：先 Is 再 As
实际业务中，常需先确认错误类别，再提取细节。比如校验失败后要定位具体字段，这时顺序很重要：
- 先
errors.Is(err, ErrValidationFailed)快速筛出校验类错误 - 再
errors.As(err, &ve)提取*ValidationError获取Field和Msg - 反过来（先
As再Is）也能工作，但多一次解包开销；且若As失败，target保持nil，后续Is就无意义
if errors.Is(err, ErrValidationFailed) {
var ve *ValidationError
if errors.As(err, &ve) {
log.Printf("字段 %s 校验失败：%s", ve.Field, ve.Msg)
}
}
最关键的一点：所有包装必须用 %w，否则 Is 和 As 都无法递归。哪怕只是加个前缀日志，也要写成 fmt.Errorf("service timeout: %w", err)，而不是 %v 或字符串拼接。
