Go errors.As 遇到指针和非指针类型怎么写目标

写错误处理时，errors.As 最容易让人困惑的不是“要不要取地址”，而是目标变量的类型到底应该对应 T 还是 *T。判断标准很简单：先看错误链里实际存放的具体值，再看这个具体值是否实现了 error。如果返回的是指针错误，就声明 var target *MyError，调用 errors.As(err, &target)；如果返回的是值错误，就声明 var target MyError，同样传入 &target。

记住两层关系：目标变量保存“匹配到的错误”，传给 errors.As 的参数是这个变量的地址。不要因为目标类型是指针，就把 target 本身直接传进去。

先看 Error 方法决定哪一种类型能匹配

假设业务错误有一个错误码。下面两个类型看起来相似，但 Error 的接收者不同，能够作为 error 使用的类型也不同。

package main

import "errors"

// ValueError 使用值接收者，因此 ValueError 和 *ValueError 都具备 Error 方法。
type ValueError struct { Code int }

func (e ValueError) Error() string { return "value error" }

// PointerError 使用指针接收者，只有 *PointerError 实现 error。
type PointerError struct { Code int }

func (e *PointerError) Error() string { return "pointer error" }

func matchValue(err error) bool {
	// 这里的 target 保存具体的值错误，参数必须是它的地址。
	var target ValueError
	return errors.As(err, &target)
}

func matchPointer(err error) bool {
	// 这里的 target 保存具体的指针错误，参数类型实际是 **PointerError。
	var target *PointerError
	return errors.As(err, &target)
}

调用形式中的第二个 & 很关键：target 是接收结果的变量，&target 才允许 errors.As 在匹配成功后把错误值写回去。即便 target 的声明本身带星号，传参仍然要取它的地址。

指针和非指针目标怎么选

真正决定写法的有两个问题：错误链中的具体值是什么，以及这个具体值是否实现了 error。可以先按下面的表格对照，不要先凭“错误一般都是指针”来猜。

第二行是常见的“指针和非指针”误区：值接收者让 *T 也拥有 Error，所以实际返回指针时仍应使用 var target *T。反过来，指针接收者不会让 T 自动实现 error，把 var target T 传给 errors.As 可能直接触发 panic。

错误被 %w 包装后，As 仍然匹配具体目标

errors.As 不只检查最外层的 err。错误实现 Unwrap() error 或 Unwrap() []error 时，它会沿错误树寻找第一个能赋值给目标的错误。这个特性适合在保留上下文的同时取出结构化字段。

package main

import (
	"errors"
	"fmt"
)

type QueryError struct { Op string; Code int }

func (e *QueryError) Error() string { return "query failed" }

func classify(err error) (int, bool) {
	var target *QueryError
	// %w 保留底层错误，As 可以穿过包装层找到 QueryError。
	if !errors.As(err, &target) {
		return 0, false
	}
	// 匹配成功后再读取字段，避免对 nil 目标解引用。
	return target.Code, true
}

func build() error {
	base := &QueryError{Op: "select", Code: 504}
	// 只增加上下文，不把底层错误改成普通字符串。
	return fmt.Errorf("load user profile: %w", base)
}

这里的关键不是包装函数名称，而是 %w 让底层关系可以被继续展开。如果把 %w 写成 %v，字符串仍然能打印出来，却不再保留供 errors.As 使用的包装关系。

接口目标适合跨多个错误类型取能力

如果调用方只关心“是否可重试”或“是否暂时性失败”，不必把所有具体错误类型列出来，可以定义一个接口目标。接口变量也要传地址，成功后通过接口方法读取能力。

type temporary interface {
	// Temporary 表达调用方真正关心的错误能力。
	Temporary() bool
}

func isTemporary(err error) bool {
	var target temporary
	// target 是接口变量，&target 让 As 写入匹配到的实现。
	return errors.As(err, &target) && target.Temporary()
}

这时不要写成 var target *temporary。接口目标的常规形式是接口变量本身，再传入它的地址；只有在正文确实要匹配某个具体指针类型时，才声明 *T 目标。

几个会让 errors.As 失效或 panic 的写法

• errors.As(err, target)：传入的是目标值，不是目标变量地址；指针目标还可能是 nil。
• var target T，但 Error 只有指针接收者：T 本身不实现 error，目标类型不合法。
• 用 errors.As 比较 errors.New("timeout")：这是值相等问题，应使用 errors.Is 或保存的哨兵错误。
• 匹配成功后忽略布尔返回值：目标可能仍未写入，读取字段前应先确认 ok。

按“实际错误值—Error 接收者—目标变量—目标地址”的顺序检查，通常很快就能定位问题。尤其在公共库里，错误类型的文档应明确返回的是值还是指针，否则调用方只能靠试错判断。

相关问题

errors.As 的第二个参数为什么必须是指针？

因为它需要在匹配成功后把错误值写入目标变量；传入 &target 才提供可写位置。

值接收者是不是只能匹配非指针目标？

不是。值接收者让 T 和 *T 都具备方法集，具体选哪一个取决于错误链中实际存放的是值还是指针。

什么时候用 errors.Is 而不是 errors.As？

要判断是否为某个固定哨兵错误或等价错误时用 errors.Is；要取出具体类型或接口能力时用 errors.As。

最后只需记一条可执行规则：先确认错误链里的真实形态，再声明同形态的目标变量，调用时统一写 errors.As(err, &target)，并检查返回的布尔值。