如何在Golang中检查错误类型_Golang错误类型断言与判断技巧

go错误处理核心是类型断言与错误包装：用Errors.as提取底层错误（需实现unwrap），errors.is判断哨兵值（需实现is），避免字符串匹配和裸断言。

Go 语言中没有传统意义上的“异常”，错误就是值，error 是一个接口。要检查错误类型，核心是**类型断言（type assertion）**和**错误包装（wrapping）**的正确处理——不这么做，errors.Is 和 errors.As 很容易失效。

用 errors.As 提取底层错误值

当你不确定错误是否由某个具体类型（比如 *os.PathError、*net.OpError）返回，又需要访问其字段时，errors.As 是首选。它会沿着错误链向上查找第一个匹配的底层错误类型。

常见错误：直接用类型断言 err.(*os.PathError)，但若错误被 fmt.Errorf("failed: %w", err) 包装过，就会失败。

实操建议：

立即学习“go语言免费学习笔记（深入）”；

• 始终优先用 errors.As(err, &target)，而不是裸断言
• target 必须是指针变量，且类型需为具体错误类型（如 *os.PathError）
• 对自定义错误，确保实现了 Unwrap() error 方法才能被正确遍历

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

用 errors.Is 判断错误是否等于某个哨兵值

适用于判断是否是预定义的错误常量，比如 io.EOF、os.ErrNotExist，或你自己定义的 var ErrTimeout = errors.New("timeout")。

关键点：

• errors.Is(err, io.EOF) 能穿透多层 %w 包装，比 err == io.EOF 安全得多
• 仅适用于可比较的错误值（errors.New 或 fmt.Errorf 不带格式动词的简单包装），不适用于含字段的结构体错误
• 不要对自定义结构体错误直接用 errors.Is 判断——它不会调用你的 Is() 方法，除非你显式实现该方法

自定义错误类型要支持标准判断逻辑

如果你写了类似 type MyError Struct { Code int; Msg String }，默认 errors.Is 和 errors.As 都无法识别它。要让它融入 Go 错误生态，必须显式支持：

• 实现 Unwrap() error：返回被包装的下层错误（如有），否则 errors.As 和 errors.Is 无法向下遍历
• 实现 Is(target error) bool：用于 errors.Is 的自定义匹配逻辑（例如按 Code 字段比对）
• 实现 Error() string：这是 error 接口的强制要求

漏掉 Unwrap 是最常见疏忽——哪怕你只包装一次，没它，上层调用 errors.As 就会停在你这层，再也找不到真正的底层错误。

避免用字符串匹配判断错误

像 strings.Contains(err.Error(), "permission denied") 看似简单，但极其脆弱：

• 错误消息可能随 Go 版本、系统语言、甚至日志封装而变化
• 无法区分语义相同但表述不同的错误（如 “access denied” vs “permission denied”）
• 完全绕过了错误类型的结构信息，丧失类型安全

真正需要区分权限类错误？用 errors.As(err, &os.SyscallError{}) 再检查 Err 字段，或用 os.IsPermission(err) 这类专用判定函数。

最易被忽略的其实是错误包装的深度和一致性：一次 %w 没加，整条错误链就断了；一个自定义错误忘了写 Unwrap，下游所有 errors.As 都会静默失败——这种问题在线上很难复现，只能靠代码审查和单元测试覆盖关键路径。