Golang错误类型处理技巧分享

Go语言中的error本质是一个简单却强大的接口，掌握其正确用法是写出健壮、可维护代码的关键：从errors.New和fmt.Errorf的合理选用，到利用%w构建可穿透的错误链，再到通过errors.Is和errors.As安全判断和提取错误信息，再到自定义error时恰当地实现Error()与Unwrap()方法——这些技巧不仅避免了常见陷阱（如盲目用==比较或硬类型断言），还兼顾了错误语义表达、调试可观测性与生产环境性能。理解“error不是特殊类型，而是可自由实现的接口”，才能真正释放Go错误处理的灵活性与表现力。

Go 中的 error 是接口，不是特殊类型

Go 语言里 error 就是一个预定义的接口：

type error interface {
    Error() string
}

最常用：用 errors.New 和 fmt.Errorf 构造错误

日常开发中，90% 的简单错误都靠这两个函数生成：

• errors.New("something went wrong")：适合固定字符串错误，底层就是返回一个私有结构体，Error() 方法直接返回该字符串
• fmt.Errorf("failed to open %s: %w", filename, err)：支持格式化，且带 %w 动词时能包裹（wrap）另一个 error，形成错误链

注意：fmt.Errorf("... %w", nil) 会 panic，传入前务必检查是否为 nil。

判断错误类型：用 errors.Is 和 errors.As，别用 == 或类型断言硬写

Go 1.13 引入了错误链支持，旧式 err == io.EOF 或 err.(someErrorType) 在包裹后会失效：

• 用 errors.Is(err, io.EOF) 判断是否等于某个已知错误（包括被 %w 包裹过的）
• 用 errors.As(err, &target) 提取底层具体错误类型，比如想拿到自定义错误里的字段
• 直接比较 err == someErrVar 只在未包裹、且是同一变量地址时才成立，基本不可靠

自定义 error 类型要实现 Error() 方法，可选加 Unwrap()

如果你需要携带额外信息（如状态码、重试次数），就定义结构体并实现 Error()：

type MyError struct {
    Code int
    Msg  string
}

func (e *MyError) Error() string { return e.Msg }

func (e *MyError) Unwrap() error { return nil } // 不包裹其他 error，返回 nil

如果要支持包裹（比如调用下游失败时带上原始 error），就让 Unwrap() 返回那个被包裹的 error：

func (e *MyError) Unwrap() error { return e.Cause }

这样 errors.Is 和 errors.As 才能穿透多层找到目标错误。没加 Unwrap() 的自定义 error，会被错误链“截断”。

真正容易被忽略的是错误链的深度和性能开销：每次 fmt.Errorf("... %w", err) 都会构造新对象，频繁包装深层调用栈可能拖慢错误生成；生产环境若只做日志记录，有时直接用 errors.New 更轻量。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang错误类型处理技巧分享》文章吧，也可关注golang学习网公众号了解相关技术文章。