Go语言把错误处理设计得非常朴素：error只是一个内置接口，拥有Error() string方法的类型都能成为错误值。这种设计的代价是，调用方从函数签名里只能看到error，看不到底层具体类型。文件不存在、权限不足、网络超时、业务校验失败，返回的都可能只是error。如果后续逻辑需要根据错误类型做不同处理，比如把*os.PathError单独拦截出来提示路径，或者把自定义的*BizError转换成统一的响应码，就必须先准确判断这个error到底属于哪一种类型。判断方式不是只有一种，直接类型断言、类型开关、errors.As各有适合的场景，本文从实际代码出发逐一说明。
类型断言和类型开关：最直接的还原方式
在没有错误包装的年代，类型断言是判断错误类型的标准做法。拿到err之后，用err.(*os.PathError)这样的表达式尝试还原底层类型。如果断言成功，ok为true，同时pathErr就是一个可以直接访问字段和方法的*os.PathError；如果断言失败，ok为false，并不会触发panic。下面是一个读取文件的例子。
package main
import (
"fmt"
"os"
)
func main() {
_, err := os.Open("not-exist.txt")
if err != nil {
if pathErr, ok := err.(*os.PathError); ok {
fmt.Println("路径错误，具体路径:", pathErr.Path)
} else {
fmt.Println("其他错误:", err)
}
}
}
当os.Open因为没有找到文件而返回错误时，底层值正是*os.PathError，所以这次断言可以命中。直接类型断言的优点是语法简单、执行快，没有额外的反射遍历。缺点也很明显：它只对“原始错误”有效。只要中间任何一层用fmt.Errorf加上了%w包装，返回的err就不再是原来的*os.PathError，而是一个新的fmt.wrapError类型，直接断言会失败。换句话说，类型断言判断的是当前错误值的静态类型，而不是它内部是否包含某个类型。
如果你需要在一个switch里同时处理多种错误类型，类型开关会更合适。它的写法和普通类型断言类似，但能一次性列出多个分支。不过类型开关同样绕不开包装问题，一旦错误被包了一层，各个case都会因为类型不匹配而走到default。这个局限在后面介绍的errors.As里得到了补足。
switch e := err.(type) {
case *os.PathError:
fmt.Println("路径错误:", e.Path)
case *os.LinkError:
fmt.Println("链接错误:", e.Err)
default:
fmt.Println("未知错误:", err)
}
errors.As：沿着%w包装链找到目标类型
Go 1.13开始引入了错误包装机制，fmt.Errorf可以配合%w把一个底层错误嵌入到新错误中，同时保留通过Unwrap() error方法回溯的能力。errors.As正是利用这个机制工作的。它接收两个参数：第一个是要检查的错误，第二个是一个指向目标类型变量的指针。如果错误链上存在某个错误可以赋值给目标类型，As会把匹配到的错误写入第二个参数，并返回true；否则返回false。下面模拟一个配置加载函数，把os.Open的错误用%w包装后再返回。
package main
import (
"errors"
"fmt"
"os"
)
func loadConfig(path string) error {
_, err := os.Open(path)
if err != nil {
return fmt.Errorf("加载配置失败: %w", err)
}
return nil
}
func main() {
err := loadConfig("config.yaml")
var pathErr *os.PathError
if errors.As(err, &pathErr) {
fmt.Println("底层是路径错误:", pathErr.Path)
} else {
fmt.Println("没有找到路径错误")
}
}
注意第二个参数的写法是&pathErr，而不是pathErr。这是因为errors.As需要把匹配结果写回到pathErr这个变量里，所以必须传它的地址。按照官方文档，第二个参数必须是非nil指针，并且指针指向的类型要么实现了error接口，要么本身就是接口类型。如果传了nil、传了非指针，或者直接传一个未取地址的pathErr（声明后为nil），都会触发panic。这个特性让As在用法上比类型断言更严格，看到panic时优先检查第二个参数是否写对。
除了简单的单层包装，errors.As可以处理任意多层的包装。例如把文件错误包装成“读取配置失败”，再包装成“初始化失败”，只要每一层都使用了%w，As就会顺着Unwrap链一层层往下找，直到找到*os.PathError或到达链尾。它内部使用反射来匹配类型，所以执行速度略慢于直接类型断言，但换来的是对包装错误的兼容能力。在大多数业务代码中，这点开销相比文件IO、网络请求可以忽略不计。
errors.Is与类型判断的边界
提到判断错误，很多资料会同时介绍errors.Is和errors.As。二者名字相近，但职责不同。errors.Is用于判断错误链上是否存在某个特定的错误值，也就是哨兵错误，例如io.EOF、sql.ErrNoRows。它比较的是“值”，而不是“类型”。如果只想区分错误种类，比如只要遇到文件不存在就提示，通常优先用errors.Is(err, os.ErrNotExist)，而不是先断言成*os.PathError再检查字段。
package main
import (
"errors"
"fmt"
"os"
)
func main() {
_, err := os.Open("not-exist.txt")
if err != nil {
if errors.Is(err, os.ErrNotExist) {
fmt.Println("文件不存在")
}
}
}
但这不意味着errors.Is和类型判断毫无关系。Go允许自定义错误类型实现Is(target error) bool方法，从而改变errors.Is的匹配规则。利用这个机制，可以让某个类型的所有实例都匹配一个哨兵错误，或者反过来，让一个错误值匹配某一类错误。下面是一个自定义业务错误类型的例子，它在Is方法里判断目标是否同为*BizError，这样errors.Is也可以承担一部分类型判断的职责。
package main
import (
"errors"
"fmt"
)
type BizError struct {
Code int
Msg string
}
func (e *BizError) Error() string {
return fmt.Sprintf("业务错误 %d: %s", e.Code, e.Msg)
}
func (e *BizError) Is(target error) bool {
_, ok := target.(*BizError)
return ok
}
func getOrder() error {
return &BizError{Code: 404, Msg: "订单不存在"}
}
func main() {
err := getOrder()
var bizErr *BizError
if errors.As(err, &bizErr) {
fmt.Println("业务错误码:", bizErr.Code)
}
if errors.Is(err, &BizError{}) {
fmt.Println("命中业务错误类型")
}
}
这段代码同时展示了As和Is的配合：As把具体类型还原出来，方便读取Code字段；Is借助自定义Is方法，判断错误是否属于业务错误这一类型。需要注意的是，自定义Is方法要避免无穷递归。如果内部再调用errors.Is，而目标类型又触发同一个Is逻辑，就可能导致栈溢出。实现时直接做类型断言通常是更安全的选择。
容易踩的三个坑：接收者、panic和误用As
第一个坑是值接收者与指针接收者不统一。假设一个自定义错误类型MyErr的Error方法定义在指针接收者上，那么只有*MyErr实现了error接口，MyErr本身并没有实现。如果函数返回的是MyErr{}值，而代码里用var e *MyErr去承接，errors.As会匹配失败。反过来，如果Error方法定义在值接收者上，那么MyErr和*MyErr都实现了error接口，匹配会更加宽松。排查这种静默失败时，先确认错误返回的到底是值还是指针，再确认Error方法的接收者。
第二个坑是errors.As的第二个参数写错导致panic。官方签名要求第二个参数必须是非nil指针，指向实现error的类型或指向任意接口。实际开发中常见的错误写法是声明var pathErr *os.PathError后，直接传pathErr，忘记取地址。此时pathErr的值为nil，传入errors.As会立即panic。正确写法是errors.As(err, &pathErr)。如果不确定自己写的目标参数是否符合要求，可以先检查它是&xxx的形式，再去运行，能有效避开这类运行时崩溃。
第三个坑是把errors.As当成errors.Is来用，或者反过来。如果业务里定义了一个哨兵错误errNotFound := errors.New("not found")，并且某处用fmt.Errorf("query user: %w", errNotFound)包装了，判断时应该用errors.Is而不是把errNotFound的类型拿出来判断。同样，当目标是读取某个自定义结构体的字段时，errors.As是最直接的选择，硬用errors.Is加上自定义Is方法虽然也能实现，但会让逻辑变绕。判断类型优先考虑As，判断具体错误值优先考虑Is，这个原则能覆盖绝大多数场景。
总的来说，Go判断error类型没有银弹。没有包装时，类型断言和类型开关足够简单；一旦进入%w包装体系，errors.As几乎是必选项。写代码时把“原始错误”和“包装错误”两种情况都考虑到，同时留意第二个参数的取地址和接收者一致性，就能避开大部分因为类型不匹配导致的静默失败。
Go error类型判断errors.As类型断言修改时间：2026-09-22 03:11:11