errors.Is 和 errors.As 不能直接判断自定义错误类型，因二者依赖 Unwrap() 实现错误链遍历，若自定义错误未实现 Unwrap()（哪怕返回 nil），则无法被识别；正确做法是显式实现 Unwrap() 方法。
errors.Is 和 errors.As 为什么不能直接判断自定义错误类型
Go 1.13 引入的 errors.Is 和 errors.As 是为「错误链」设计的，它们只认 Unwrap() 方法返回的下一层错误，不支持直接比对未包装的原始错误值。如果你定义了一个结构体错误但没实现 Unwrap()，errors.As 就永远找不到它。
- 常见错误现象：
errors.As(err, &myErr)返回false，即使err == myErr成立 - 正确做法：自定义错误必须显式实现
Unwrap() error，哪怕只返回nil（表示链终止） - 典型场景：封装底层库错误时，比如用
fmt.Errorf("read failed: %w", io.ErrUnexpectedEOF)，%w才触发可包装行为 - 参数差异：
errors.Is比对的是语义相等（递归调用Is()），而==只比地址或值；errors.As是类型断言的链式版本，不是类型转换
fmt.Errorf("%w") 包装后，原错误的字段还能访问吗
不能直接访问。用 %w 包装后，原始错误被藏在 Unwrap() 返回值里，它的字段（比如 .Code 或 .Msg）对外不可见，除非你手动解包并做类型断言。
- 常见错误现象：包装后的错误打印出来有完整信息，但
err.Code报错 —— 因为err类型是*fmt.wrapError，没有Code字段 - 实操建议：需要保留字段访问能力时，不要只依赖
%w；要么让自定义错误自身支持Unwrap()+ 字段透出方法（如ErrorCode()），要么在包装前先提取关键字段存到新错误中 - 性能影响：每次
errors.As都会逐层调用Unwrap()，如果错误链过深（>5 层），可能带来微小开销，但通常可忽略
errors.Unwrap 是不是总能拿到最底层错误
不是。errors.Unwrap 只返回当前错误的直接下一层，且只调用一次；它不递归，也不跳过中间层。想拿最底层，得自己循环调用，或者用 errors.Cause（非标准，需第三方库）。
- 常见错误现象：对一个嵌套三层的错误连续两次调用
errors.Unwrap，第二次返回nil—— 因为第二层错误的Unwrap()返回了nil，不代表它没底层，只是它没继续包装 - 使用场景：日志记录时想提取根源错误（比如区分
os.IsNotExist），应配合循环或封装工具函数 - 兼容性注意：Go 1.20+ 新增
errors.Join，返回的错误Unwrap()返回切片，此时errors.Unwrap行为不同，别假设它一定返回单个 error
os.IsNotExist(err) 为啥有时失效，和 errors.Is 的关系是什么
os.IsNotExist 内部其实就用了 errors.Is(err, os.ErrNotExist)，但它只能识别标准库定义的那几个哨兵错误。一旦你用 fmt.Errorf("xxx: %w", os.ErrNotExist) 包装过，它依然有效；但如果你自己 new 了一个 os.ErrNotExist 的副本，或者用了别的包定义的类似错误，os.IsNotExist 就失效了。
立即学习“go语言免费学习笔记（深入）”；
- 容易踩的坑：把
os.ErrNotExist当普通变量复制、序列化再反序列化，会导致指针/值丢失，errors.Is判定失败 - 实操建议：优先用
errors.Is(err, os.ErrNotExist)替代os.IsNotExist，更明确、更可控；所有自定义“不存在”类错误，都应包装os.ErrNotExist而非模仿它新建 - 参数差异：
os.IsNotExist是特化函数，errors.Is是通用接口；后者还能用于自定义哨兵错误，比如errors.Is(err, ErrValidationFailed)
错误链不是银弹，包装层级多了，调试时反而难定位真正出问题的地方。别为了“符合规范”而多包一层，尤其是 HTTP handler 里把每个 error 都 %w 上去 —— 那只会让日志变厚，让 As 变慢，让同事抓狂。
