Go errors.As 为什么拿不到指针错误类型

Go 的 errors.As 拿不到指针错误类型，通常不是包装层太多，而是目标变量的类型和错误的真实动态类型没有对上。最容易混淆的是：错误值是 *ValidationError 时，目标变量要声明成 *ValidationError，传给 errors.As 的才是它的地址 &target；如果错误值本身是 ValidationError，目标变量则要声明成 ValidationError。

先做一个最小的错误排障项目

为了避免把接口、指针和包装混在一起，我们先构造一个只负责校验用户输入的小例子。这个小项目的验收目标很明确：当调用方收到错误后，能够拿到 Field 字段，而不是只打印一行错误文本。

package main

import (
    "errors"
    "fmt"
)

// ValidationError 使用指针接收者实现 error，适合携带可变的诊断字段。
type ValidationError struct {
    Field string
    Reason string
}

// Error 返回给日志或用户看的摘要，不负责暴露结构化字段。
func (e *ValidationError) Error() string {
    return fmt.Sprintf("字段 %s 校验失败：%s", e.Field, e.Reason)
}

// validateUser 返回指针错误；这决定了错误的动态类型是 *ValidationError。
func validateUser() error {
    return &ValidationError{Field: "email", Reason: "格式不正确"}
}

func main() {
    err := validateUser()

    // target 的声明类型要和错误的动态类型 *ValidationError 对齐。
    var target *ValidationError
    if errors.As(err, &target) {
        fmt.Println("需要修正字段：", target.Field)
    }
}

这里的关键不是“调用了两次指针”，而是两个位置承担的职责不同：target 用来接收匹配到的 *ValidationError，&target 是让 errors.As 能够把匹配结果写回这个变量。

为什么目标变量必须是 *T，而不是 **T

errors.As 要求第二个参数是一个非 nil 指针，并把错误树中可赋值给该目标的具体错误写进去。对于上例，错误的动态值是 *ValidationError，所以先声明 var target *ValidationError，再传入它的地址。

可以把这段关系写成一张小表：

因此，下面这种写法看起来像是“目标类型更具体”，实际却会匹配失败：

// 这里 target 是 ValidationError，但 err 中保存的是 *ValidationError。
var target ValidationError
if errors.As(err, &target) {
    fmt.Println(target.Field)
}

它不是把 *ValidationError 自动解引用成 ValidationError。errors.As 做的是类型可赋值判断，不会替调用方改变错误的具体类型。

Error 方法的接收者决定了哪些值能装进 error

排查 errors.As 前，先看自定义错误的 Error 方法。若方法写成 func (e *ValidationError) Error() string，通常只有 *ValidationError 满足 error 接口；若写成值接收者 func (e ValidationError) Error() string，则值和指针都可以满足接口，但函数最终返回哪一个，仍然决定错误树里的动态类型。

type ValueError struct {
    Code string
}

// 值接收者让 ValueError 和 *ValueError 都拥有 Error 方法。
func (e ValueError) Error() string {
    return "错误码：" + e.Code
}

func makeValueError() error {
    // 这里返回的是值，动态类型就是 ValueError，不是 *ValueError。
    return ValueError{Code: "INVALID_INPUT"}
}

func readValueError(err error) {
    // 目标变量也必须是值类型，As 才能把 ValueError 写入其中。
    var target ValueError
    if errors.As(err, &target) {
        fmt.Println("值错误：", target.Code)
    }
}

这也是“明明 Error 方法是值接收者，为什么 As 还是拿不到”的常见来源：值接收者只扩大了接口实现范围，没有把已经返回的 ValueError 自动变成 *ValueError，也没有把指针返回值自动变成值。

包装错误时，先确认 %w 有没有保留错误链

如果错误经过了业务层包装，errors.As 能否找到目标还取决于包装方式。fmt.Errorf 使用 %w 时会保留底层错误，使用 %v 只会把错误格式化成文本。

func loadUser() error {
    err := validateUser()
    if err != nil {
        // %w 保留底层 *ValidationError，调用方仍可使用 errors.As。
        return fmt.Errorf("加载用户失败：%w", err)
    }
    return nil
}

func inspect(err error) {
    var target *ValidationError
    if errors.As(err, &target) {
        fmt.Println("包装链中的字段：", target.Field)
        return
    }

    // 没有匹配时不要读取 target 的字段，先保留原始错误上下文。
    fmt.Println("未找到 ValidationError：", err)
}

如果把 %w 改成 %v，外层错误里只剩文本，底层的 *ValidationError 不再是可遍历的错误节点，errors.As 返回 false 就是预期结果。

用类型矩阵定位 As 返回 false 的原因

项目里遇到问题时，按下面的顺序核对，通常比盯着 errors.As 这一行更快：

1. 看返回语句：是 return T{}，还是 return &T{}。
2. 看 Error 的接收者：是 T 还是 *T。
3. 看包装语句：跨层返回时是否使用了 %w。
4. 看目标声明：指针错误用 var target *T，值错误用 var target T。
5. 最后确认第二个参数是 &target，且 target 在调用前没有被手动替换成 nil 指针以外的错误状态。

还有一个容易误判的点：errors.As 找到的是错误树中按遍历顺序遇到的第一个匹配项。如果链上同时出现多个可匹配类型，先匹配到的节点会被写入目标变量。此时应该回头检查包装层的设计，而不是继续叠加指针层级。

相关问题

errors.As 的第二个参数为什么不能直接传 target

因为 As 需要通过指针把匹配结果写入目标变量。传入 target 而不是 &target，就没有可写回的位置；同时 target 本身还必须是与错误具体类型对应的变量。

指针接收者的自定义错误应该总是返回指针吗

如果 Error 只由指针类型实现，返回指针是自然且直接的选择。调用方再用 var target *T 配合 errors.As(err, &target) 获取结构化字段。

只想判断错误类别时还需要拿到具体字段吗

如果只需要判断固定哨兵错误，优先考虑 errors.Is；只有需要读取自定义错误字段或调用其方法时，才使用 errors.As。

记住一句话就够了：先确认错误树里的真实动态类型，再声明同类型的 target，最后把 target 的地址传给 errors.As。指针错误不是要声明成 **T，而是要声明成 *T 后传入 &target。