errors.Is 用于递归判断错误是否等于某预定义值，errors.As 用于安全提取包装链中特定类型的错误实例；二者均依赖 Unwrap 方法，要求自定义错误导出字段且接收者为指针。
errors.Is 和 errors.As 是 Go 1.13 引入的错误判断核心工具，用于替代过去脆弱的 == 或类型断言。它们能正确处理包装错误（如 fmt.Errorf("wrap: %w", err)），是现代 Go 错误处理的标配。
什么时候该用 errors.Is 而不是 ==
当你需要判断一个错误是否「等于」某个预定义的错误值（比如 io.EOF、自定义的 ErrNotFound），且该错误可能被多层 %w 包装时，必须用 errors.Is。
-
==只比较最外层错误指针或值，一旦被fmt.Errorf("failed: %w", err)包裹就失效 -
errors.Is(err, io.EOF)会递归解包，直到找到匹配的底层错误 - 常见误用：对自定义错误使用
==判断，但实际返回的是fmt.Errorf("xxx: %w", myErr)
示例：
var ErrNotFound = errors.New("not found")
func find() error {
return fmt.Errorf("in db: %w", ErrNotFound) // 被包装
}
err := find()
fmt.Println(errors.Is(err, ErrNotFound)) // true
fmt.Println(err == ErrNotFound) // false
为什么 errors.As 比直接类型断言更安全
errors.As(err, &target) 用于提取包装链中某个特定类型的错误实例（比如提取 *os.PathError 或自定义结构体），它比 if e, ok := err.(*MyError) 更健壮。
立即学习“go语言免费学习笔记（深入）”；
- 类型断言只检查最外层错误类型；
errors.As会逐层Unwrap()直到找到匹配类型 - 目标变量必须是指针（
&t），且类型需实现error接口 - 如果错误链里有多个同类型错误，
As只返回第一个匹配的
示例：
type MyError struct{ Msg string }
func (e *MyError) Error() string { return e.Msg }
err := fmt.Errorf("wrap: %w", &MyError{"boom"})
var e *MyError
if errors.As(err, &e) {
fmt.Println(e.Msg) // "boom"
}
errors.Is 和 errors.As 的性能与兼容性注意点
两者都是轻量级操作，但仍有几个实际约束容易被忽略：
- 仅对实现了
Unwrap() error或Unwrap() []error的错误生效；纯字符串错误（如errors.New("x")）无法被进一步解包 - Go 1.20+ 开始支持多错误解包（
Unwrap() []error），此时Is和As会遍历所有分支 - 不要在循环中频繁调用
errors.As提取同一类错误——若已知错误结构稳定，可提前解包一次缓存结果 - 第三方库若未用
%w包装错误（比如直接拼接字符串），Is/As就完全无效
最常被漏掉的一点：你写的自定义错误类型，如果希望被 As 正确识别，必须导出字段且接收者为指针——否则解包后无法赋值给目标变量。
