4、错误类型断言：类型断言检查错误、errors.As与类型switch、自定义错误类型的层次结构

在 Go 业务错误处理中，仅仅返回错误是不够的——调用方往往需要根据错误的具体类型或行为做出不同的决策。Go 提供了三种主要的错误类型断言机制：直接类型断言、errors.As 以及类型 switch。本章将深入剖析这三种方式的适用场景、实现原理，并展示如何构建可维护的自定义错误层次结构。

4.1 错误类型断言的核心机制

错误类型断言允许调用方从 error 接口值中提取出具体的错误类型信息。Go 1.13 引入的 errors.As 函数进一步规范了这一过程，使其能够沿着错误链进行遍历查找。

4.2 直接类型断言与 errors.As 对比

直接类型断言适用于无包装的错误场景，而 errors.As 是处理包装错误的推荐方式。

// 直接类型断言（不遍历错误链）
if e, ok := err.(*ValidationError); ok {
    fmt.Printf("字段: %s, 原因: %s\n", e.Field, e.Reason)
}

// errors.As（遍历错误链）
var ve *ValidationError
if errors.As(err, &ve) {
    fmt.Printf("字段: %s, 原因: %s\n", ve.Field, ve.Reason)
}

4.3 类型 switch 与错误分支处理

当需要根据多种错误类型执行不同逻辑时，类型 switch 提供了清晰的语法结构。但需注意：标准类型 switch 不遍历错误链，需要结合 errors.As 或手动解包。

// 标准类型 switch（仅匹配最外层）
switch e := err.(type) {
case *NotFoundError:
    return http.StatusNotFound, e.Message
case *ConflictError:
    return http.StatusConflict, e.Message
default:
    return http.StatusInternalServerError, "未知错误"
}

// 结合 errors.As 遍历错误链（推荐）
var (
    nf  *NotFoundError
    cf  *ConflictError
)
switch {
case errors.As(err, &nf):
    return http.StatusNotFound, nf.Message
case errors.As(err, &cf):
    return http.StatusConflict, cf.Message
default:
    return http.StatusInternalServerError, "未知错误"
}

4.4 自定义错误类型的层次结构

构建合理的错误类型层次结构，是业务错误处理领域边界清晰化的关键。一个良好的层次结构应遵循以下原则：

• 基类抽象：定义基础错误接口或结构体，包含通用字段（如 Code、Message、Timestamp）。
• 领域分类：按业务领域（用户、订单、支付）划分一级错误类型。
• 具体细化：在每个领域下定义具体错误（如 UserNotFound、OrderExpired）。
• 行为接口：为错误添加行为方法（如 Temporary() bool、Retryable() bool）。

// 基础错误结构体
type BusinessError struct {
    Code      string
    Message   string
    Timestamp time.Time
    Err       error  // 内部包装错误
}

func (e *BusinessError) Error() string {
    return fmt.Sprintf("[%s] %s", e.Code, e.Message)
}

func (e *BusinessError) Unwrap() error {
    return e.Err
}

// 领域错误：用户模块
type UserError struct {
    *BusinessError
    UserID string
}

// 具体错误：用户未找到
type UserNotFoundError struct {
    *UserError
}

// 具体错误：用户已禁用
type UserDisabledError struct {
    *UserError
    DisabledReason string
}

// 行为接口：是否可重试
func (e *UserDisabledError) Retryable() bool {
    return false
}

4.5 错误层次结构设计图

下图展示了典型的业务错误层次结构，以及类型断言在其中的作用路径：

4.6 类型断言与错误链遍历

当错误被多次包装时，errors.As 的链遍历能力尤为重要。下图展示了 errors.As 如何穿透多层包装找到目标类型：

4.7 实战：构建可扩展的错误断言体系

在实际项目中，建议将错误类型断言封装为断言函数，减少调用方的重复代码：

// 断言函数：判断错误是否为特定业务错误
func IsUserNotFound(err error) bool {
    var target *UserNotFoundError
    return errors.As(err, &target)
}

func IsOrderExpired(err error) bool {
    var target *OrderExpiredError
    return errors.As(err, &target)
}

// 断言函数：获取错误中的业务码
func GetBusinessCode(err error) string {
    var be *BusinessError
    if errors.As(err, &be) {
        return be.Code
    }
    return "UNKNOWN"
}

// 断言函数：判断错误是否可重试
func IsRetryable(err error) bool {
    type retryable interface {
        Retryable() bool
    }
    var r retryable
    if errors.As(err, &r) {
        return r.Retryable()
    }
    return false
}

4.8 错误类型断言对比总结