Go错误判断：errors.Is与errors.As使用详解

在 Go 中，由于错误包装机制（如 `fmt.Errorf("wrap: %w", err)`）的存在，直接使用 `==` 比较或 `switch err.(type)` 类型断言会失效——即使错误语义相同或底层类型一致，也会判断失败；正确做法是统一用 `errors.Is` 判断错误语义相等（如是否为 `io.EOF` 或 `os.ErrNotExist`），用 `errors.As` 安全提取底层具体错误类型（如 `*os.PathError` 或 `*url.Error`）以获取上下文信息，二者常组合使用：先 `Is` 快速分类，再 `As` 精准取值，同时务必检查错误非 nil 再调用，才能写出健壮、可维护的错误处理逻辑。

直接说结论：用 errors.Is 判断错误是否等于某个已知错误（比如 io.EOF），用 errors.As 提取底层具体错误类型（比如把包装过的 *os.PathError 拿出来）。别用 == 或 switch err.(type) 直接比，Go 的错误包装机制会让它们失效。

为什么不能直接用 == 比较错误

Go 1.13 引入错误包装（fmt.Errorf("wrap: %w", err)），导致同一语义的错误可能被多层包装。此时原始错误被嵌套在 Unwrap() 链里，err == io.EOF 必然为 false，哪怕它底层就是 io.EOF。

常见错误现象：
• 打开不存在的文件后判断 os.IsNotExist(err) 返回 false
• 自定义错误包装后，err == myErr 始终不成立
• errors.Is(err, io.EOF) 才能稳定捕获流结束信号

实操建议：
• 所有需要语义判断的场景（如“是不是权限不足”“是不是路径不存在”）统一走 errors.Is
• 不要自己写递归调用 Unwrap() —— errors.Is 已内置遍历整个链
• 如果你写的库返回错误，记得用 %w 包装，否则下游无法用 Is/As

errors.As 怎么安全提取底层错误类型

errors.As 不是类型断言，而是沿着错误链向下查找第一个匹配目标类型的错误值，并把指针赋给传入的变量。它解决的是“这个错误具体是哪种实现”的问题。

使用场景：
• 需要访问 *os.PathError 的 Path 字段
• 想调用自定义错误类型的 RetryAfter() 方法
• HTTP 客户端错误中提取 *url.Error 的 URL 和 Err

实操建议：
• 第二个参数必须是指向接口或具体类型的指针，例如 &pathErr，不是 pathErr
• 如果错误链里没有匹配类型，errors.As 返回 false，且目标变量保持零值 —— 别忘了检查返回值
• 不要用 err.(*os.PathError)，包装后会 panic

var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Printf("failed on path: %s", pathErr.Path)
}

Is 和 As 的典型组合用法

实际项目里常同时用两者：先用 errors.Is 快速判断错误类别，再用 errors.As 提取上下文信息做精细化处理。

常见错误现象：
• 只用 errors.Is 知道“是网络错误”，但不知道连的是哪个地址
• 只用 errors.As 提取出 *url.Error，却漏判了它是否属于可重试错误

实操建议：
• 先查是否是预定义错误（errors.Is(err, context.Canceled)），再查具体类型（errors.As(err, &urlErr)）
• 对于自定义错误类型，确保实现了 Unwrap() error 方法（如果需要被包装）
• 注意性能：这两函数内部会遍历错误链，但链长通常很短，无需提前缓存结果

容易被忽略的一点：如果错误本身是 nil，errors.Is(nil, someErr) 返回 false，errors.As(nil, &x) 返回 false —— 这符合直觉，但有人会忘记判空就直接调用。

文中关于golang,Go语言的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Go错误判断：errors.Is与errors.As使用详解》文章吧，也可关注golang学习网公众号了解相关技术文章。