如果让你评选 Go 语言最令人头疼的特性，错误处理一定榜上有名。曾几何时，我们面对层层嵌套的错误，只能无奈地写下 if err != nil；曾几何时，我们在错误链中迷失方向，无法精准定位问题的根源。如今，Go 1.13 带来的 errors.Is 和 errors.As，就像一道曙光，照亮了错误处理的黑夜。结合我的经验，这篇文章就来一起探索这对"兄弟"背后的设计美学。
从"一错到底"到"层层追溯"
在 Go 的早期版本中，错误处理可以用"简单粗暴"来形容。我们用 error 接口来表示错误，用 errors.New() 创建最基础的文件错误，用 fmt.Errorf() 输出格式化的错误信息。
// 传统的错误创建
err := errors.New("something went wrong")
err = fmt.Errorf("failed to process: %s", msg)但这种方式的局限很快就显现出来。想象一下，你的业务代码层层嵌套：HTTP 请求 → 业务逻辑 → 数据访问 → 数据库操作。当数据库返回一个错误时，你如何判断这是"连接超时"还是"数据不存在"？
传统做法是字符串匹配：
if strings.Contains(err.Error(), "timeout") {
// 处理超时
}这种做法极其脆弱，任何错误信息的微小变化都可能导致逻辑失效。更糟糕的是，它完全破坏了错误的类型系统，让错误处理变成了"看文识字"的游戏。
.unwrap：error 接口的进化
Go 1.13 对 error 接口进行了优雅的扩展，引入了 Unwrap() 方法：
type error interface {
Error() string
Unwrap() error // Go 1.13 新增
}这个看似简单的方法，却为错误处理打开了一扇大门。通过 Unwrap()，错误可以"解包"——一个包装错误可以返回它内部的原始错误，从而形成一条"错误链"。
// 错误包装
err := database.Query("SELECT...")
return fmt.Errorf("query failed: %w", err)这里的关键是 %w 占位符，它让 fmt.Errorf 返回的错误包含了对原始错误的引用，并且实现了 Unwrap() 方法。现在，我们可以沿着这条错误链向上追溯，找到问题的真正源头。
errors.Is：火眼金睛的错误值匹配
errors.Is 的作用是在错误链中查找与目标错误"相等"的错误。它的签名简洁明了：
func errors.Is(err, target error) bool简单来说，它会遍历整个错误链，检查是否有任何一个错误与 target 相等。这解决了 Go 错误处理中的一个核心难题：被包装的错误如何被正确识别？
// 定义一个 sentinel error（哨兵错误）
var ErrNotFound = errors.New("resource not found")
func findUser(id int) error {
// 底层返回 ErrNotFound
err := db.Find(id)
if err != nil {
return fmt.Errorf("find user failed: %w", err)
}
return nil
}
func main() {
err := findUser(123)
// 即使错误被层层包装，依然能正确识别
if errors.Is(err, ErrNotFound) {
fmt.Println("用户不存在")
}
}这还不是全部。errors.Is 的真正强大之处在于它支持自定义的"等价"判断。如果你的错误类型实现了 Is() 方法，你可以定义什么叫做"相等"：
type ValidationError struct {
Field string
Message string
}
func (e *ValidationError) Is(target error) bool {
if v, ok := target.(*ValidationError); ok {
return e.Field == v.Field
}
return false
}这样，两个不同消息但相同字段的 ValidationError 就可以被认为是"相等"的。
errors.As：抽丝剥茧的错误类型提取
如果说 errors.Is 是"火眼金睛"，那么 errors.As 就是"火眼金睛加神兵利器"。它不仅能判断错误类型，还能将错误"提取"出来：
func errors.As(err error, target interface{}) bool使用 errors.As，你可以从错误链中获取具体的错误类型实例：
// 定义带额外信息的错误类型
type ParseError struct {
File string
Line int
Col int
}
func (e *ParseError) Error() string {
return fmt.Sprintf("%s:%d:%d: parse error", e.File, e.Line, e.Col)
}
func parseConfig() error {
err := parseFile("config.json")
if err != nil {
return fmt.Errorf("parse config failed: %w", err)
}
return nil
}
func main() {
err := parseConfig()
var parseErr *ParseError
if errors.As(err, &parseErr) {
fmt.Printf("解析错误位于 %s 的第 %d 行\n",
parseErr.File, parseErr.Line)
}
}和 errors.Is 类似，errors.As 也支持自定义行为。如果你的错误类型实现了 As() 方法，你可以控制如何提取目标类型。
写在最后
从 errors.New 到 fmt.Errorf，从字符串匹配到 errors.Is 和 errors.As，Go 的错误处理经历了优雅的进化。这两个函数不仅解决了错误包装和类型识别的难题，更重要的是，它们建立了一套统一的错误处理范式。
errors.Is让你能精确判断"这是不是我等待的那个错误"errors.As让你能提取"这个错误到底是什么类型的"
下次当你面对层层嵌套的错误时，不妨试试这对组合。它们会让你的代码更加健壮，错误处理更加优雅。这，就是 Go 追求的"简单而强大"的哲学。
