errors.is 查整个错误链中是否存在指定错误值，通过逐层调用 unwrap() 实现；要求错误必须用 %w 包装、目标错误为同一变量（如 io.eof），否则匹配失败。
errors.Is 判断的是错误链顶端还是底层原因
errors.Is 查的是整个错误链里有没有某个目标错误值，不是只看最外层的错误。它会逐层调用 Unwrap()，直到找到匹配的 error 值，或者返回 nil 结束遍历。
常见错误现象：用 errors.Is(err, io.EOF) 返回 false，但其实错误里确实包了 io.EOF——问题往往出在中间某层用了 fmt.Errorf("xxx: %w", err)，但你传进去的 err 本身是 nil，导致整个链断掉；或者用了 fmt.Errorf("xxx: %v", err)（没加 %w），直接丢掉了包装关系。
- 必须确保错误是用
%w包装的，否则errors.Is找不到底层错误 - 如果自己实现了
Unwrap() error方法，要保证它返回正确的下一层错误，不能返回nil或固定值 -
errors.Is比较的是error值的相等性（==），不是字符串或类型，所以目标错误必须是同一个变量或导出的包级变量（如io.EOF、os.ErrNotExist）
为什么 errors.Is(err, os.ErrNotExist) 有时不生效
根本原因是 os.ErrNotExist 是一个变量，不是类型，而很多自定义错误或第三方库返回的“文件不存在”错误，并不是这个变量本身，而是另一个新构造的 error 值。
使用场景：比如调用 os.Open 失败后判断是否为“文件不存在”，应该用 errors.Is(err, os.ErrNotExist)；但如果用的是 os.Stat + 自己封装的检查逻辑，且内部用了 fmt.Errorf("not found: %w", os.ErrNotExist)，那依然能命中；可一旦写成 fmt.Errorf("not found: %v", os.ErrNotExist)，就彻底断链。
-
os.ErrNotExist只在os包内部某些函数中直接返回，其他地方基本不会复用这个变量 - 有些文件系统操作（如通过
syscall层）可能返回&PathError{Op: "open", Path: "...", Err: syscall.ENOENT}，这种错误不包含os.ErrNotExist，errors.Is查不到，得用errors.As提取*os.PathError再判断Err字段 - Go 1.13+ 的
os.IsNotExist函数其实是对errors.Is(err, os.ErrNotExist)的封装，但做了额外兼容（比如识别syscall.ENOENT等底层错误），更稳妥
errors.Is 和 errors.As 的关键区别在哪
errors.Is 解决“是不是某个已知错误值”，errors.As 解决“能不能转成某个错误类型”。两者用途完全不同，混用会导致逻辑错乱。
常见错误现象：想判断错误是否是 *os.PathError 类型，却写了 errors.Is(err, &os.PathError{}) ——这永远返回 false，因为 errors.Is 不做类型断言，也不比较结构体内容，只比指针或值相等。
- 判断具体错误值（如
io.EOF、sql.ErrNoRows）→ 用errors.Is - 需要访问错误内部字段（如
PathError.Path、TimeoutErr.Timeout()）→ 必须用errors.As提取指针 -
errors.As会匹配错误链中任意一层的类型，但只返回第一个匹配到的，不保证是顶层还是底层 - 如果既要看值又要取字段，通常先
errors.Is快速过滤，再errors.As提取细节，避免不必要的类型断言开销
自定义错误配合 errors.Is 的正确写法
如果你自己定义错误并希望它能被 errors.Is 正确识别，核心就一条：提供稳定的、可比较的错误值，而不是每次 new 一个新实例。
错误示范：return fmt.Errorf("validation failed: %w", errors.New("invalid input")) ——errors.New 每次都新建对象，errors.Is(err, errors.New("invalid input")) 必然失败。
- 导出一个包级变量，如
var ErrInvalidInput = errors.New("invalid input")，所有地方都复用它 - 如果需要携带上下文信息，用
fmt.Errorf("user %s: %w", name, ErrInvalidInput)，保持%w链完整 - 不要在自定义错误类型里把
Unwrap()实现成返回errors.New(...)，那会制造不可比较的新错误 - 如果必须动态生成错误值（比如带状态码），那就别指望
errors.Is，改用errors.As+ 类型判断，或自定义Is(target error) bool方法
复杂点在于：错误链不是树而是单链，Unwrap() 只能返回一个下层错误。这意味着你没法同时表达“既是网络超时又是认证失败”这种多因错误——errors.Is 只能找到第一个匹配项，后面的会被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
