Golang错误处理中的类型断言_从interface{}提取具体错误

应使用 errors.as 而非手动类型断言，因其对 nil 安全且能递归遍历错误链；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），它会无限循环直到栈溢出。

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

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

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