Go errors.As 怎么定位嵌套错误：类型匹配、包装链与接口边界

线上接口把底层文件错误包装成业务错误后，日志里只剩下一长串调用链，真正需要的是判断它是不是 *os.PathError、net.Error 或自定义错误。Go 的 errors.As 就是沿着 %w 建立的错误链寻找目标类型，但目标变量的指针层级写错时，代码要么编译不过，要么永远匹配不到。

先看一个真实的错误包装链

假设配置加载器从文件读取规则，底层返回 *os.PathError，服务层为了补充业务上下文再包装一次：

func loadRules(path string) error {
    _, err := os.ReadFile(path)
    if err != nil {
        return fmt.Errorf("load rules: %w", err)
    }
    return nil
}

func refresh(path string) error {
    if err := loadRules(path); err != nil {
        return fmt.Errorf("refresh config: %w", err)
    }
    return nil
}

这里有两层文本说明，但真正的错误对象仍在链的末端。判断字符串里有没有 no such file 很脆弱，应该直接拿类型做分支。

errors.As 的目标变量应该怎么声明

最常见的目标是 *os.PathError。因为它本身是一个指针类型，目标变量声明为指针，再把目标变量的地址传给 As：

err := refresh("/etc/myapp/rules.yaml")

var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Printf("path=%s op=%s cause=%v", pathErr.Path, pathErr.Op, pathErr.Err)
    // 可以根据 pathErr.Err 做文件不存在、权限不足等细分处理
}

可以把这段代码读成一句话：“在 err 链里找一个能赋值给 *os.PathError 的错误，并把它放进 pathErr。”第二个参数是 any，但它必须是一个非 nil 指针，指向可接收匹配结果的变量。

为什么不能直接写成 PathError 值

os.PathError 的错误方法通常由指针接收者实现，所以错误链里保存的是 *os.PathError。下面这种写法目标类型不对：

var pathErr os.PathError
if errors.As(err, &pathErr) { // 目标是 os.PathError，不是 *os.PathError
    // 不应这样写
}

在标准库约束下，这类目标很容易触发“目标类型不满足 error”或无法匹配。遇到自定义错误时也遵循同一原则：先看它是用值接收者还是指针接收者实现 Error()，再决定目标变量的类型。

接口目标适合处理哪些边界

如果调用方只关心错误具备的能力，不关心它的具体结构，可以把目标变量设为接口类型。比如做网络超时判断就可以这么写：

var timeoutErr interface {
    Timeout() bool
}
if errors.As(err, &timeoutErr) && timeoutErr.Timeout() {
    // 进入可重试或延迟处理分支
}

接口目标的好处是解耦具体包，但也要确认方法集合真的代表业务条件。不要为了让 As 返回 true 而定义一个过于宽泛的空接口，否则匹配到的错误无法帮助决策。

三种写法放在一起核对

如果只是判断是否为 os.ErrNotExist，应该写 errors.Is(err, os.ErrNotExist)。As 负责“拿到某种类型”，Is 负责“是否等于某个哨兵错误”，两者用途不同。

包装链断在哪里，匹配就停在哪里

把 %w 改成 %v 看起来只是格式变化，实际会丢掉链：

return fmt.Errorf("refresh config: %v", err)

此时日志仍然可能包含 open /etc/myapp/rules.yaml: no such file or directory，但 errors.As 已经没有对象可继续遍历。另一个常见坑是自定义包装器只实现 Unwrap() error 的一部分逻辑，或者在聚合错误时遗漏了子错误；这类代码要用测试确认链是否保持。

用小测试验证类型和回退路径

func TestRefreshMissingFile(t *testing.T) {
    err := refresh(filepath.Join(t.TempDir(), "missing.yaml"))

    var pathErr *os.PathError
    if !errors.As(err, &pathErr) {
        t.Fatalf("errors.As failed: %v", err)
    }
    if !errors.Is(err, os.ErrNotExist) {
        t.Fatalf("errors.Is failed: %v", err)
    }
}

测试同时检查类型和哨兵错误，能防止后来有人把某层 %w 改成 %v 却只看日志仍然“像是正常”的情况。每次调整自定义错误结构后，先运行这个测试，再决定是否修改上层分支。

相关问题

errors.As 会修改目标变量吗？

会。匹配成功后，目标变量会被赋值为错误链里对应的错误对象；匹配失败时目标变量会保持原有值，所以不要在同一个目标变量上复用之前的判断结果。

错误信息相同可以不用 errors.As 吗？

不建议。错误文本是给开发者排查问题看的，类型和哨兵错误才是稳定可靠的程序判断依据。

自定义错误应该返回值还是指针？

如果错误包含较多字段或需要在链中保持同一对象，通常返回指针更直观；关键是让声明、Error() 接收者和 errors.As 目标三者保持一致。

最后检查清单

• 需要继续识别底层类型时，包装使用 %w。
• 匹配具体错误类型前，先确认错误链里实际保存的是值类型还是指针类型。
• 按错误对象取字段用 As，按哨兵错误判断用 Is。
• 为包装链写一个同时覆盖 As 和 Is 的回归测试。