errors.Is判断错误链中是否存在目标哨兵错误，errors.As提取底层错误类型；二者配合使用可穿透多层包装，但需先判空、优先用预定义哨兵错误，避免对临时错误实例调用Is。
errors.Is 判断错误是否等于某个目标错误
errors.Is 用于判断一个错误链中是否存在与目标错误相等的错误（基于 == 或实现了 Is(error) 方法）。它不关心错误类型，只关心“是不是同一个错误实例”或“是否被标记为相等”。
常见错误现象：用 errors.Is(err, io.EOF) 正确；但用 errors.Is(err, fmt.Errorf("not found")) 几乎总返回 false，因为每次 fmt.Errorf 都新建一个地址不同的错误实例。
- 只对预定义的哨兵错误（如
io.EOF、os.ErrNotExist）或你自己显式定义的变量错误使用errors.Is - 不要对临时构造的错误（
errors.New/fmt.Errorf调用结果）做errors.Is判断 - 若错误来自第三方库，需查阅其文档是否导出了可比的哨兵错误；否则应优先考虑
errors.As
errors.As 提取底层错误值并做类型断言
errors.As 用于从错误链中向下查找第一个能被赋值给指定类型的错误值，并将其实例存入目标变量。它解决的是“这个错误底层是不是某种具体类型”的问题。
典型使用场景：你收到一个 os.PathError 包裹
Err 字段看是不是 syscall.EACCES；或者处理 net.OpError 时想提取底层的 syscall.Errno。
- 目标变量必须是指针类型（如
*os.PathError），errors.As才能写入 - 如果错误链中存在多个同类型错误，
errors.As只取第一个匹配的 - 注意类型兼容性：例如
syscall.Errno实现了error，但它不是结构体指针，不能用*syscall.Errno接收，而要用**syscall.Errno或更稳妥地先转成syscall.Errno再比较
示例：
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("path: %s, op: %s", pathErr.Path, pathErr.Op)
}
为什么不能只用 == 或 switch err.(type)？
直接用 err == io.EOF 在简单场景可行，但一旦错误被 fmt.Errorf("wrap: %w", err) 或 errors.Wrap（旧库）包裹，就失效了——因为外层错误不是 io.EOF 本身。
switch err.(type) 只能匹配最外层错误类型，无法穿透包装。比如 fmt.Errorf("read failed: %w", os.ErrNotExist) 的类型是 *fmt.wrapError，不是 *os.PathError，更不是 os.ErrNotExist 的底层类型。
-
errors.Is和errors.As是 Go 1.13+ 错误链标准方案，专为多层包装设计 - 手动递归调用
errors.Unwrap实现类似逻辑非常容易漏层或 panic，不推荐 - 第三方错误包装库（如
github.com/pkg/errors）在 Go 1.13+ 后基本可弃用，因其Causer/Unwrapper接口已被标准库覆盖
嵌套错误里混用 Is 和 As 的实际顺序
真实错误往往既需要判断“是不是某个哨兵错误”，又需要提取“底层是不是某种结构体”。二者不互斥，但有逻辑先后：通常先 errors.Is 快速识别已知错误，再用 errors.As 做精细处理。
容易踩的坑：在未确认错误非 nil 的情况下直接传给 errors.As，会导致 panic（因内部对 nil 解引用）。虽然标准库文档没明说，但实测 errors.As(nil, &x) 返回 false 不 panic；不过为保险起见，仍建议显式判空。
- 总是先检查
err != nil，再调用errors.Is或errors.As - 如果
errors.Is(err, someSentinel)为 true，通常无需再As——除非你要访问该哨兵错误的字段（但哨兵错误一般无字段） - 如果
errors.As(err, &x)成功，可进一步对x做errors.Is(x.Err, ...)判断其内部错误
复杂点在于错误链可能深达 5–6 层，且中间混用标准库和旧式包装；这时候靠肉眼调试几乎不可行，建议配合 fmt.Printf("%+v", err) 查看完整链路。
