在 Go 1.13 之前，主要使用两种方式处理特定类型的错误：

1. 类型断言

if customErr, ok := err.(*MyCustomError); ok {
    // 处理自定义错误
    fmt.Println(customErr.Code)
}

2. 通过 switch 判断类型:

switch e := err.(type) {
case *InternalError:
    fmt.Println("自定义错误:", e.Code)
case *os.PathError:
    fmt.Println("路径错误:", e.Path)
default:
    fmt.Println("未知错误")
}

这些传统方式的局限性在于只能检查错误的最外层类型，无法处理被包装的错误，并且代码冗长且容易遗漏嵌套错误。

error.As 基本用法

var err *InternalError
if errors.As(err, &err) {
    fmt.Printf("错误代码: %d\n", err.Code)
}

errors.As 的优势

1. 处理嵌套错误链

package main

import (
    "errors"
    "fmt"
)

type ValidationError struct {
    Field   string
    Message string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("%s: %s", e.Field, e.Message)
}

func process() error {
    // 模拟一个深层嵌套的错误链
    err := &ValidationError{Field: "email", Message: "invalid format"}
    return fmt.Errorf("注册失败: %w", 
        fmt.Errorf("用户验证失败: %w", 
            fmt.Errorf("输入验证错误: %w", err)))
}

func main() {
    err := process()

    // 传统方式：无法找到被包装的错误
    if ve, ok := err.(*ValidationError); ok {
        fmt.Println("传统方式找到:", ve.Field) // 不会执行
    }

    // 使用 errors.As：成功找到深层错误
    var ve *ValidationError
    if errors.As(err, &ve) {
        fmt.Printf("errors.As 找到: %s - %s\n", ve.Field, ve.Message)
        // 输出: errors.As 找到: email - invalid format
    }
}

2. 清晰统一的错误处理方式

errors.As 与 errors.Is 形成了统一的错误处理模式：

// 检查特定的错误值
if errors.Is(err, io.EOF) {
    // 处理 EOF
}

// 检查特定的错误类型
var pathErr *os.PathError
if errors.As(err, &pathErr) {
    // 处理所有路径相关的错误
    fmt.Printf("操作 %s 失败: %v\n", pathErr.Path, pathErr.Err)
}

errors.As 会在成功匹配时自动将错误赋值给目标变量。

实际应用场景

场景1: 处理中间件错误

func ErrorMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                log.Printf("panic recovered: %v", err)
                http.Error(w, "内部服务器错误", http.StatusInternalServerError)
            }
        }()
        
        // 执行处理程序
        rr := &responseRecorder{ResponseWriter: w}
        next.ServeHTTP(rr, r)
        
        // 检查是否有错误
        if rr.err != nil {
            handleHTTPError(w, rr.err)
        }
    })
}

func handleHTTPError(w http.ResponseWriter, err error) {
    // 尝试匹配各种错误类型
    var validationErr *ValidationError
    if errors.As(err, &validationErr) {
        http.Error(w, validationErr.Message, http.StatusBadRequest)
        return
    }
    
    var authErr *AuthError
    if errors.As(err, &authErr) {
        http.Error(w, "需要认证", http.StatusUnauthorized)
        return
    }
    
    // 默认错误
    http.Error(w, "服务器错误", http.StatusInternalServerError)
}

2. 处理多个不同的错误类型

func AnalyzeError(err error) {
    // 尝试多种可能的错误类型
    var targets []interface{} = []interface{}{
        (*json.UnmarshalTypeError)(nil),
        (*json.SyntaxError)(nil),
        (*os.PathError)(nil),
    }

    for _, target := range targets {
        if errors.As(err, &target) {
            // 根据具体类型处理
            handleSpecificError(target)
            return
        }
    }

    // 未知错误类型
    log.Printf("未知错误类型: %T", err)
}

性能考虑

使用的时候担心过 errors.As 的性能，因为它需要遍历整个错误链。但测试下来即使是深度嵌套，每次检查也只需要几十纳秒，而且在代码清晰度上有很大优势。