Go 接口中 error 无法用 == 区分类型，应优先用 errors.As 提取底层错误（如 *os.PathError），用 errors.Is 判断哨兵错误（如 io.EOF、os.ErrNotExist），避免直接类型断言或 err == sentinel。
Go 语言中接口错误（error）本身不提供类型信息，直接用 == nil 只能判断是否出错，无法区分错误来源或具体原因——必须用类型断言、errors.As 或 errors.Is 才能安全识别和处理。
用 errors.As 提取底层错误值
当错误是包装型（比如 fmt.Errorf("failed: %w", io.EOF) 或 os.PathError），== 和 == nil 都无法匹配原始错误类型。此时应优先用 errors.As：
-
errors.As(err, &target)会沿错误链向下查找第一个能赋值给target的错误实例（支持指针或值接收） - 适用于需要调用底层错误方法的场景，例如提取
*os.PathError的Path字段 - 比类型断言更健壮：即使中间有多个
%w包装，也能穿透找到目标类型
示例：
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("access denied to %s", pathErr.Path)
}
用 errors.Is 判断错误是否为某类“哨兵错误”
对于预定义的哨兵错误（如 io.EOF、os.ErrNotExist），errors.Is 是唯一推荐方式：
- 它会递归检查整个错误链，判断是否存在某个哨兵值（
==比较） - 不能用于自定义错误结构体（除非显式实现了
Is方法） - 避免写
err == io.EOF—— 如果错误被fmt.Errorf("%w", io.EOF)包装，该判断就失效
示例：
if errors.Is(err, os.ErrNotExist) {
return createDefaultConfig()
}
避免直接类型断言 err.(*MyError)
硬编码类型断言在错误链变长或中间插入新包装层时极易 panic：
立即学习“go语言免费学习笔记（深入）”；
-
err.(*MyError)在err是*fmt.wrapError时直接 panic - 若必须用断言，请先用
errors.As替代；或确保错误来自可信内部调用（无第三方包装） - 自定义错误类型建议实现
Unwrap() error和Is(error) bool，以兼容标准库错误处理逻辑
自定义错误类型要小心实现 Is 和 Unwrap
如果你定义了带字段的错误（如 type ValidationError struct { Field string; Msg string }），默认不支持 errors.Is 或 errors.As：
- 想让
errors.Is(err, ErrInvalid)生效，需在类型上实现Is(target error) bool方法 - 想让
errors.As(err, &v)能提取该类型，需确保它是错误链中的一环（即返回非 nil 的Unwrap()） - 若只是简单哨兵，直接用
var ErrInvalid = errors.New("invalid")即可，无需结构体
真正复杂的错误分类逻辑，往往藏在 Unwrap 返回路径和 Is 的匹配策略里，这里最容易漏掉递归终止条件或误判包装层级。
