如何在Golang中利用类型断言处理特定错误 Go语言多维错误处理

怎么用 err.(type) 判断错误是不是自定义类型

go 里没有“异常继承”概念，Errors.Is 和 errors.As 是推荐方式，但类型断言仍是底层常用手段。直接写 err.(*MyError) 看似简单，但容易 panic——只要 err 不是该指针类型，运行时就崩。

正确做法是用双返回值形式做安全断言：

if myErr, ok := err.(*MyError); ok {     // 使用 myErr.Code 或 myErr.Msg }

常见错误现象：把 err.(MyError)（值类型）和 err.(*MyError)（指针类型）搞混，尤其当你的错误是用 errors.New 包装过、或通过 fmt.Errorf 构造时，原始值可能已丢失指针语义。

• 自定义错误建议统一实现为指针类型（即 func (*MyError) Error() String），避免值接收器导致断言失败
• 如果错误链中嵌套了其他错误（比如用 fmt.Errorf("wrap: %w", err)），类型断言只对最外层有效；要查内层得用 errors.Unwrap 或 errors.As
• 断言前先确认 err != nil，否则 nil 做类型断言会得到零值 + ok=false，不 panic 但逻辑易错漏

为什么 errors.As 比类型断言更可靠

errors.As 能穿透错误包装（%w），自动遍历整个错误链找匹配类型，而类型断言只能看当前层级。这是它存在的根本原因。

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

使用场景很明确：你要处理的是被 fmt.Errorf("failed to x: %w", err) 包裹过的错误，且目标类型在链中间或底层。

var myErr *MyError if errors.As(err, &myErr) {     // myErr 现在指向匹配到的实例 }

注意参数必须传指针（&myErr），不是值；否则 errors.As 无法写入。这也是最容易踩的坑——传错类型会导致始终返回 false，还看不出哪错了。

• errors.As 兼容接口类型断言（比如 Interface{ Timeout() bool }），比硬写结构体指针更灵活
• 性能上略低于直接类型断言（有链遍历开销），但日常 http/DB 错误处理中可忽略
• Go 1.13+ 才有，老项目若还在用 1.12 及以前，得自己递归 Unwrap + 断言

errors.Is 和 errors.As 别混用的典型场景

errors.Is 查的是错误是否等于某个值（比如 os.ErrNotExist），或实现了 Is 方法并返回 true；errors.As 查的是能否转换成某类型。两者目的完全不同。

常见错误现象：想判断错误是不是网络超时，却写了 errors.Is(err, &net.OpError{}) ——这永远 false，因为 Is 不做类型匹配，只做值比较或调 Is() 方法。

• 判断是否是特定错误值（如 io.EOF、sql.ErrNoRows）→ 用 errors.Is
• 想取错误里的字段（如 Timeout()、Code()、RetryAfter）→ 用 errors.As
• 既想判又想取，优先用 errors.As，成功后调对应方法（比如 myErr.Timeout()），别再补一层 errors.Is

多维错误处理时，fmt.Errorf 的 %w 不能乱加

加 %w 是为了保留原始错误以便后续用 errors.As 或 errors.Is 分析，但不是所有地方都该加。加错位置会让错误链变长、语义模糊，甚至暴露不该透出的内部错误。

典型反例：HTTP handler 里把数据库错误原样 %w 包进响应错误，结果用户看到 "pq: duplicate key violates unique constraint" ——这既是安全风险，也破坏封装。

• 对外返回错误时，只 %w 那些需要被上层决策的错误（比如重试、降级、日志分类），其余应转为通用错误（如 errors.New("service unavailable")）
• 日志记录时建议用 fmt.Sprintf("%+v", err)，它会打印完整错误链和栈，比 err.Error() 有用得多
• 测试中验证错误链要用 errors.Is/errors.As，别依赖 strings.Contains(err.Error(), "xxx")，后者脆弱且不可靠

错误链不是越深越好，关键在每一层是否承担明确职责：谁负责分类，谁负责修饰，谁负责兜底。断言只是工具，真正难的是设计错误传播的边界。