Go errors.As 匹配自定义错误指针时为什么拿不到值

排查 Go 自定义错误时，如果 errors.As 返回了 false，或者返回成功却发现目标变量还是空，最先检查的不是错误文本，而是两件事：错误接口里装的是值还是指针，以及传给 errors.As 的地址层级是否匹配。错误动态类型是 *ValidationError 时，正确写法是声明 var target *ValidationError，再传入 &target，也就是一个 **ValidationError。

先确认 errors.As 需要的是目标类型的地址

errors.As 做的是“从错误树里找到一个可赋值给目标类型的错误，并把它写入 target”。因此第二个参数不是要匹配的错误值，而是目标变量的地址。这个区别在自定义错误是指针时尤其明显。

package main

import (
    "errors"
    "fmt"
)

// ValidationError 携带可以被调用方消费的结构化字段。
type ValidationError struct {
    Field string
    Code  string
}

// 指针接收者表示 *ValidationError 实现 error。
func (e *ValidationError) Error() string {
    return fmt.Sprintf("%s: %s", e.Field, e.Code)
}

func load() error {
    // %w 保留内部错误，errors.As 可以继续向里查找。
    return fmt.Errorf("request rejected: %w", &ValidationError{
        Field: "email",
        Code:  "invalid",
    })
}

func main() {
    err := load()

    // 变量装的是错误指针，所以 target 的类型是 *ValidationError。
    var target *ValidationError
    ok := errors.As(err, &target)
    if !ok {
        fmt.Println("not a validation error")
        return
    }
    fmt.Println(target.Field, target.Code)
}

这里的变量类型关系是：target 为 *ValidationError，&target 为 **ValidationError。外层 fmt.Errorf 只是让错误树多了一层，匹配仍会找到内部的 *ValidationError。实际验收可盯住三个结果：ok == true、target != nil、结构化字段可读。

指针错误为什么要用 **ValidationError

最常见的错法是把目标写成值变量：

var target ValidationError
if errors.As(err, &target) {
    // 这里看似传入了地址，但它的类型是 *ValidationError。
    fmt.Println(target.Code)
}

&target 的类型确实是 *ValidationError，但它表示“把一个 ValidationError 值写到 target”。而当前错误的动态类型是 *ValidationError，两者不是同一个可赋值类型，所以不会匹配。正确修复不是把 & 再删掉，而是让目标变量先声明成指针，再传它的地址。

另一个危险写法是 var target *ValidationError; errors.As(err, target)。此时传入的是 nil 指针，既没有给 As 一个可写的目标地址，还可能触发它对非法 target 的 panic。遇到“拿不到值”时，可以先打印 fmt.Printf("%T\\n", err) 看错误当前的动态类型，再决定目标声明。

值接收者和指针接收者要跟返回值一起判断

Error 方法的接收者会影响实现 error 的集合，但不会替你决定函数返回时装入接口的具体形态。下面的表就是判断入口：

如果 Error 使用指针接收者，通常只能把 *ValidationError 放进 error；如果使用值接收者，值和指针都可能实现 error，最终还要看返回表达式是 ValidationError{} 还是 &ValidationError{}。因此不要只看类型定义，要同时看构造和返回处。

用一张小表把 errors.As 的目标写对

可以把排查缩成三项：先看 %T，再看目标变量声明，最后看传入的是不是它的地址。只要三项一致，错误是否被包装通常不会再造成干扰。

1. 先识别动态类型：确认函数实际返回的是 ValidationError 还是 *ValidationError。
2. 再声明目标：动态类型带星号，目标变量也带星号；动态类型不带星号，目标变量就用值类型。
3. 最后传地址：目标变量无论是值还是指针，传给 errors.As 的都是 &target，并检查 ok。

在支持 Go 1.26 或更高版本的项目中，还可以用 errors.AsType[*ValidationError](err) 直接返回匹配值和布尔值，少写一层目标地址；但理解 errors.As 的地址规则仍然有价值，因为旧版本代码、接口目标和自定义 As(any) bool 仍会遇到同样的类型边界。

常见问题

errors.As 返回 false，是不是必须先 errors.Unwrap？

通常不需要。errors.As 会沿 Unwrap() error 或 Unwrap() []error 形成的错误树查找，%w 包装可以直接匹配。手动 Unwrap 反而容易丢掉后续包装层。

为什么 errors.Is 能用，errors.As 却拿不到自定义字段？

errors.Is 判断是否匹配某个错误值或哨兵错误；errors.As 才负责把具体错误对象写入目标变量。两者用途不同，字段读取必须检查 As 的目标类型和地址层级。

自定义错误实现 As 方法时还看动态类型吗？

还要看，但匹配规则可能由自定义的 As(any) bool 接管。这个方法必须识别传入目标的形态并负责写入目标；没有特殊映射需求时，直接使用标准的类型匹配更容易维护。