Golang如何比较错误信息_errors Is与As使用说明

errors.Is 和 errors.As 是

Go 1.13+ 唯一推荐的错误判断方式，可穿透 %w 包装；Is 用于判断是否等于哨兵错误，As 用于提取底层错误结构体指针。

errors.Is 和 errors.As 是 Go 1.13+ 处理错误类型判断的**唯一推荐方式**，它们能穿透多层包装错误（比如用 %w 包裹的错误），而传统 == 或类型断言会失效。

什么时候用 errors.Is：判断是否等于某个哨兵错误

当你只想知道“是不是这个错”，比如文件不存在、EOF、自定义业务失败标识，就用 errors.Is。它比较的是错误值本身，不是类型。

• 必须使用包级变量定义的哨兵错误（var ErrNotFound = errors.New("not found")），不能每次 errors.New("not found") 新建——否则 Is 永远返回 false
• 支持标准库已实现 Is() 方法的错误，如 os.ErrNotExist、io.EOF
• 对 fmt.Errorf("read failed: %w", os.ErrNotExist) 这类包装错误依然有效
• 性能比 errors.As 略高，适合前置快速过滤

if errors.Is(err, os.ErrNotExist) {
    log.Println("文件不存在，跳过处理")
}

什么时候用 errors.As：提取错误底层结构体或字段

当你需要访问错误内部字段（比如路径、错误码、原始消息）或调用其方法时，用 errors.As。它做的是类型匹配 + 赋值，目标变量必须是指针。

• 目标变量必须是指向具体类型的指针，例如 *os.PathError、*MyCustomError
• 只取错误链中**第一个匹配的实例**（最内层被包装的那个），不会遍历全部
• 如果错误链里有多个同类型错误，As 不会合并或跳过，只取第一个找到的
• 不支持接口类型直接匹配（如 error），必须是具体类型或实现了该接口的结构体指针

var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Printf("操作 %s 失败于路径 %s: %v", pathErr.Op, pathErr.Path, pathErr.Err)
}

常见踩坑点：为什么你的判断总失败？

绝大多数错误类型判断失效，都源于这三类误用：

• 用 err == os.ErrNotExist —— 包装后外层错误不相等，直接返回 false
• 用 err.(*os.PathError) 类型断言 —— 无法穿透 %w 包装，运行时 panic
• 用 errors.New("permission denied") 当作目标传给 Is —— 每次新建对象地址不同，恒不相等；必须用包级变量
• 对自定义错误没实现 Unwrap() error 方法 —— 导致 Is 和 As 无法向下递归，卡在第一层

组合使用才真正健壮：先 Is 再 As

实际业务中，常需先确认错误类别，再提取细节。比如校验失败后要定位具体字段，这时顺序很重要：

• 先 errors.Is(err, ErrValidationFailed) 快速筛出校验类错误
• 再 errors.As(err, &ve) 提取 *ValidationError 获取 Field 和 Msg
• 反过来（先 As 再 Is）也能工作，但多一次解包开销；且若 As 失败，target 保持 nil，后续 Is 就无意义

if errors.Is(err, ErrValidationFailed) {
    var ve *ValidationError
    if errors.As(err, &ve) {
        log.Printf("字段 %s 校验失败：%s", ve.Field, ve.Msg)
    }
}

最关键的一点：所有包装必须用 %w，否则 Is 和 As 都无法递归。哪怕只是加个前缀日志，也要写成 fmt.Errorf("service timeout: %w", err)，而不是 %v 或字符串拼接。