Go errors.AsType 如何做泛型错误分类：从类型断言到零值边界

处理文件配置时，调用方往往既想知道“是不是不存在”，又想拿到 *os.PathError 里的操作和路径。Go 1.26 提供的 errors.AsType 把这类类型提取写成泛型返回值，少一个目标指针，也更容易看出失败时的零值边界。

errors.AsType[T](err) 适合“我需要具体错误类型”的场景；是否属于某个哨兵错误，仍然用 errors.Is 判断，两者不要混成一个条件。

先分清：类型提取和错误分类不是一回事

假设配置目录暂时不存在，底层返回的可能是一个包着路径、操作名和原始原因的 *os.PathError。如果业务只需要决定“创建目录还是提示权限问题”，用 errors.Is 就够了；如果日志还要输出 Op、Path 和 Err，就需要做类型提取。

这两个判断可以连续出现，但职责不同：

最小配方：用 errors.AsType 取出 PathError

下面的函数只做一件事：打开配置文件，遇到路径错误时把真实路径写进诊断信息。errors.AsType 会沿着包装错误链寻找 *os.PathError，不需要先声明一个目标变量再把它的地址传给 errors.As。

package main

import (
    "errors"
    "fmt"
    "os"
)

func describeOpen(path string) error {
    _, err := os.Open(path)
    if err == nil {
        return nil
    }

    pathErr, ok := errors.AsType[*os.PathError](err)
    if ok {
        return fmt.Errorf("open %s: op=%s path=%s cause=%v", path, pathErr.Op, pathErr.Path, pathErr.Err)
    }
    return err
}

这里的 err 是输入，errors.AsType 负责沿链查找，*os.PathError 是目标类型，pathErr 才是后续读取字段的值。四个名字在日志和代码审查时都应保持明确，别把 ok 误读成“文件已经打开成功”。

图 1：err 进入 errors.AsType，匹配到 *os.PathError 后才读取 pathErr 字段。

零值边界：类型没找到时不要读取字段

泛型返回值的便利之处，也带来了一个必须写清楚的边界：当错误链里没有目标类型时，第二个返回值为 false，第一个返回值是 T 的零值。对 *os.PathError 来说，这个零值就是 nil。

func classify(err error) string {
    if err == nil {
        return "ok"
    }

    if errors.Is(err, os.ErrNotExist) {
        return "missing"
    }

    target, ok := errors.AsType[*os.PathError](err)
    if !ok || target == nil {
        return "other"
    }
    return target.Op
}

errors.Is 放在前面，是因为“文件不存在”往往是业务真正关心的分类；随后才用 errors.AsType 补充具体操作名。即使当前实现通常会同时拿到 *os.PathError，也不要省掉 !ok || target == nil，这样改动错误包装类型后不会引入空指针访问。

图 2：先用 errors.Is 判定 ErrNotExist，再检查 target == nil 决定是否读取具体类型。

包装错误时，两个判断仍然沿着同一条链工作

业务层通常会用 %w 加上下文，而不是把原错误转成普通字符串。只要包装保留在错误链里，errors.Is 可以继续找到 os.ErrNotExist，errors.AsType 也可以继续找到 *os.PathError。

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

err := openConfig("/etc/demo/app.yaml")
if errors.Is(err, os.ErrNotExist) {
    // 创建默认配置或返回可理解的提示。
}
pathErr, ok := errors.AsType[*os.PathError](err)
if ok {
    fmt.Println(pathErr.Op, pathErr.Path)
}

相反，使用 fmt.Errorf("load config: %v", err) 会丢掉可遍历的包装关系。表面上日志还在，机器判断却失效了；这也是排查“明明是不存在，errors.Is 却返回 false”时优先检查的地方。

Go 1.25 及更早版本的兼容写法

errors.AsType 是 Go 1.26 的标准库能力。旧版本可以使用等价的目标变量写法，业务语义不变：

var pathErr *os.PathError
if errors.As(err, &pathErr) {
    fmt.Println(pathErr.Op, pathErr.Path)
}

如果库要同时支持多个 Go 版本，可以把新旧实现放在不同的构建标签文件中，或暂时继续使用 errors.As。升级的收益主要是类型提取更紧凑，不值得为了少两行代码破坏项目的最低 Go 版本约束。

常见问题

errors.AsType 找不到类型时会返回什么？

返回目标类型的零值和 false。如果目标是指针类型，先检查布尔值，再确认指针不为 nil。

errors.AsType 能替代 errors.Is 吗？

不能。errors.AsType 用于提取具体类型，errors.Is 用于判断错误链是否匹配某个目标错误。

为什么包装后 errors.Is 仍然有效？

使用 %w 会保留可遍历的错误链；使用 %v 只把错误格式化成文本，无法继续做链式匹配。

项目还没升级 Go 1.26 怎么办？

继续使用 errors.As(err, &target)。它能覆盖同一个判断场景，等最低版本提升后再切换。

把判断顺序固定成一条可复查的规则

遇到文件或配置错误时，可以先判断业务类别，再提取具体类型，最后读取字段：err == nil 处理成功，errors.Is(err, os.ErrNotExist) 处理缺失，errors.AsType[*os.PathError](err) 补充操作与路径，其他错误保留原始上下文。这个顺序短，但把零值、包装和版本兼容三个容易漏掉的边界都留在了代码里。