Go errors.As 怎么匹配实现接口的错误类型

要让 errors.As 匹配“实现某个接口的错误”，先声明一个接口类型变量，再把变量地址传给 errors.As。匹配成功后，变量会被设置为错误树中第一个可赋值给该接口的错误值，你可以直接调用接口方法，而不必知道具体错误结构体。

核心写法是 var target Retryable 配合 errors.As(err, &target)。这里传的是“接口变量的地址”，不是接口值本身，也不是随手创建的 new(any)。

按能力接口匹配错误

我更倾向于为调用方定义最小能力接口。例如上层只关心“多久后可重试”，就不必依赖底层网络库或客户端包的具体错误类型。

type Retryable interface {
    RetryAfter() time.Duration
}

func handleRequest(err error) time.Duration {
    var retryable Retryable
    if errors.As(err, &retryable) {
        // As 会把错误树中首个实现 Retryable 的错误写入接口变量
        return retryable.RetryAfter()
    }

    // 没有匹配能力时，按不可自动重试处理
    return 0
}

Retryable 不必暴露错误的字段，也不必与具体包绑定。错误值本身仍然必须实现 error，同时只要它的方法集满足 Retryable，就能被该接口目标接住。

多层包装不会挡住匹配

直接写 err.(Retryable) 只检查当前最外层动态值；只要外层是 fmt.wrapError，断言通常就失败。errors.As 会沿着 Unwrap() error 或 Unwrap() []error 形成的错误树查找，因此适合保留上下文后的能力判断。

type serviceError struct {
    wait time.Duration
}

func (e *serviceError) Error() string {
    return "服务暂时不可用"
}

func (e *serviceError) RetryAfter() time.Duration {
    return e.wait // 指针类型同时实现 error 和 Retryable
}

func callService() error {
    base := &serviceError{wait: 3 * time.Second}
    // 两层 %w 包装保留业务上下文，也保留底层类型能力
    return fmt.Errorf("同步用户失败: %w", fmt.Errorf("调用上游: %w", base))
}

标准库规定，errors.As 先检查错误本身，再按深度优先顺序检查子错误。若错误树里有多个实现同一接口的错误，只会返回第一个匹配项。需要汇总所有匹配时，应自行遍历错误树，而不是重复调用同一次 As。

target 为什么经常写错

errors.As 的第二个参数必须是非空指针，并且指针指向的类型要么实现 error，要么本身是接口类型。接口匹配因此要传 &retryable。如果 target 形状不符合要求，函数会 panic，而不是简单返回 false。

还要检查方法接收者。如果 Error() 或能力方法定义在指针接收者上，只有 *MyError 实现接口，MyError 值本身不实现。创建和包装错误时应保持指针形态一致。

版本说明：errors.As 从 Go 1.13 开始提供。官方文档：https://pkg.go.dev/errors#As

相关问题

errors.As 和 errors.Is 有什么区别？

As 用于提取某种具体类型或接口能力；Is 用于判断错误树中是否存在等价的目标错误值。需要调用错误对象的方法时通常使用 As。

接口必须嵌入 error 吗？

不是必须。target 可以指向任意接口类型，但被找到的值本身来自错误树，必然是错误值。实践中可按调用方真正需要的方法定义最小接口。