Golang类型断言错误处理技巧

在Go错误处理中，应优先使用`errors.As`而非手动类型断言来安全提取错误类型——它对nil安全、能递归穿透多层包装的错误链，避免因`err.(*MyError)`导致的panic；同时需明确区分`errors.Is`（匹配哨兵错误值）与`errors.As`（提取错误实例）的不同用途，自定义错误必须正确实现`Unwrap`方法以支持错误链遍历，否则下游所有类型提取将静默失败，而循环引用或过深嵌套更可能引发性能问题甚至栈溢出，这些看似细微的设计疏漏，往往成为生产环境难以排查的隐性陷阱。

用 errors.As 而不是手动类型断言

直接对 error 做 err.(MyError) 很容易 panic，尤其当 err 是 nil 或底层类型不匹配时。Go 1.13 引入的 errors.As 才是安全提取错误类型的正解——它会递归检查错误链（wrapped error），且对 nil 安全。

• 手动断言 err.(*os.PathError) 在 err 是 fmt.Errorf("wrap: %w", pathErr) 时失败，而 errors.As(err, &pathErr) 成功
• 必须传入指针：第二个参数是 *T 类型，不是 T
• 返回 bool 表示是否找到匹配项，别忽略返回值

var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Println("路径错误:", pathErr.Path)
}

什么时候该用 errors.Is 而不是 errors.As

errors.Is 判断的是“是否等于某个已知错误值”，比如 os.ErrNotExist；errors.As 判断的是“是否能转成某类错误”。两者解决的问题完全不同，混用会导致逻辑错乱。

• errors.Is(err, os.ErrNotExist) → 检查是不是“文件不存在”这个具体值（或其包装）
• errors.As(err, &pathErr) → 检查底层有没有 *os.PathError 实例，不管它是不是 os.ErrNotExist
• 常见误用：想判断是否是网络超时，却写 errors.Is(err, context.DeadlineExceeded) —— 这只对裸错误有效；实际中多数是 net/http 或 database/sql 包装过的，得用 errors.As 提取 *net.OpError 再看 .Timeout()

自定义错误类型要实现 Unwrap 才能被正确遍历

如果你自己封装错误并希望 errors.As 和 errors.Is 能穿透它，必须显式实现 Unwrap() error 方法。否则错误链在你这层就断了。

• 没实现 Unwrap：外层调用 errors.As(wrappedErr, &inner) 返回 false
• 正确做法：返回内部错误，且注意 nil 安全（如果 innerErr 是 nil，Unwrap 应返回 nil）
• 不要在 Unwrap 里做日志、格式化或额外判断——它只负责“向下透出”

type MyError struct {
    msg string
    cause error
}
func (e *MyError) Error() string { return e.msg }
func (e *MyError) Unwrap() error { return e.cause }

嵌套过深或循环引用会让 errors.As 变慢甚至卡住

errors.As 默认最多遍历 10 层错误链，超过就停止。但如果你的错误链人为构造出循环（比如 A 包装 B，B 又包装 A），它会无限循环直到栈溢出。

• 典型场景：中间件或日志库在 defer 中反复包装同一错误
• 没有运行时检测循环引用，只能靠代码审查和测试覆盖
• 性能敏感路径（如高频 RPC 错误处理）建议先用 errors.Is 快速匹配已知哨兵值，再按需用 errors.As 提取细节

最麻烦的不是写错，是忘了自定义错误要实现 Unwrap，或者在包装时无意引入循环——这两处一漏，下游所有 errors.As 都会静默失效。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~