errors.Is只能判断是否包含目标错误值，依赖Unwrap链逐层比较值相等性，不支持类型断言；自定义错误需实现Unwrap或用%w包装才能被识别。
errors.Is 为什么不能判断自定义错误类型
errors.Is 只能识别通过 fmt.Errorf 带 %w 动词包装的错误，或实现了 Unwrap() error 方法的错误。它不依赖类型断言，而是靠逐层调用 Unwrap() 向下查找是否“包含”某个目标错误值。
如果你直接返回 &MyError{} 或 errors.New("xxx")，它没有 Unwrap 方法，errors.Is(err, myErr) 就永远是 false，哪怕 err 就是那个 *MyError 实例。
- 正确做法：用
fmt.Errorf("wrap: %w", myErr)包装后再返回 - 错误做法：直接
return &MyError{}后期望errors.Is(err, &MyError{})成功 - 注意：
errors.Is比较的是错误值（value），不是类型；若想按类型判断，请用errors.As
errors.Is 和 errors.As 的核心区别在哪
errors.Is 判断“是否等于某个错误值”，常用于预定义的哨兵错误（如 io.EOF、os.ErrNotExist）；errors.As 则尝试把错误链中任意一层“转换为指定类型”，用于提取自定义错误结构体中的字段。
-
errors.Is(err, io.EOF)→ 查找错误链里有没有io.EOF这个具体值 -
errors.As(err, &e)→ 查找错误链里有没有能赋值给*MyError的那一层，并把值拷贝进e - 两者都从最外层错误开始，逐层
Unwrap()，但匹配逻辑完全不同 - 如果错误没实现
Unwrap()，它们都只检查当前层
哨兵错误必须是变量，不能是函数返回值
定义哨兵错误时，必须用 var 声明全局变量，例如 var ErrNotFound = errors.New("not found")。如果写成函数返回 errors.New("not found")，每次调用都生成新对象，errors.Is(err, ErrNotFound()) 必然失败——因为比较的是指针或底层字符串地址，不是语义相等。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 正确：
var ErrTimeout = errors.New("timeout") - ❌ 错误：
func ErrTimeout() error { return errors.New("timeout") } - ⚠️ 补充：使用
fmt.Errorf("%w", ErrTimeout)包装后，errors.Is仍可识别原哨兵值
嵌套多层错误时 errors.Is 的实际行为
errors.Is 不止看第一层，它会递归调用 Unwrap() 直到返回 nil，只要中间任何一层 == 目标错误，就返回 true。这意味着它适合判断“是否由某类错误引发”，但不适合精确定位哪一层出错。
err := fmt.Errorf("db query failed: %w", fmt.Errorf("network error: %w", io.EOF))
errors.Is(err, io.EOF) // true
errors.Is(err, fmt.Errorf("network error: %w", io.EOF)) // false —— 因为是值比较，不是类型或结构匹配
- 每一层包装都应使用
%w，否则断开Unwrap链，errors.Is就无法穿透 - 不要在中间层用
fmt.Errorf("msg: %v", err)，这会丢失原始错误引用 - 若需保留上下文又不想干扰
Is判断，可用fmt.Errorf("msg: %w", err)并确保被包装错误支持Unwrap
Unwrap() 方法，如果返回的不是原始错误（比如返回了新构造的错误），errors.Is 也会失效。它依赖的是错误链的“值同一性”，不是语义等价。 
