在Go语言1.13版本之前，错误处理主要依赖error接口和类型断言，一旦错误被fmt.Errorf用%v包装，原始错误类型或值就会丢失，导致调用方难以准确判断错误种类。Go 1.13在标准库errors中加入了Is和As函数，配合fmt.Errorf的%w动词，让错误链上的判定与提取变得规范且可靠。
errors.Is的基本用法与原理
errors.Is(err, target)用于判断err错误链中是否存在与target相等的错误。它会递归调用Unwrap方法，逐层展开错误，直到找到匹配项或链结束。相等性判断首先比较两者是否完全是同一个变量，若实现了Is(error) bool方法，则使用该方法来判定。
下面示例展示如何使用errors.Is识别被多层包装的同一 sentinel 错误：
package main
import (
"errors"
"fmt"
)
var ErrNotFound = errors.New("not found")
func readFile() error {
return fmt.Errorf("open failed: %w", ErrNotFound)
}
func main() {
err := readFile()
if errors.Is(err, ErrNotFound) {
fmt.Println("捕获到 ErrNotFound，即使它被包装过")
}
}
上述代码中，readFile返回的错曾被%w包装，但errors.Is仍能顺着错误链识别出ErrNotFound。若用err == ErrNotFound直接比较则会失败，因为外层是一个新的包装错误。
使用errors.Is的优势在于它与错误包装解耦：无论错误被包装多少层，只要链上某节点等于目标，就能正确匹配。这在库函数返回通用错误、业务层附加上下文时尤为有用。
errors.As的类型提取机制
errors.As(err, target)的作用是将错误链中第一个能赋值给target所指向类型的错误提取出来。第二个参数必须是一个非空指针，且指向某种错误类型（或实现了error接口的类型）。函数返回true时，target已被赋值为链上匹配的错误实例。
以下示例定义了一个自定义错误类型，并使用errors.As提取它：
package main
import (
"errors"
"fmt"
)
type ValidationError struct {
Field string
Msg string
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("field %s: %s", e.Field, e.Msg)
}
func process() error {
inner := &ValidationError{Field: "age", Msg: "must be positive"}
return fmt.Errorf("process error: %w", inner)
}
func main() {
err := process()
var ve *ValidationError
if errors.As(err, &ve) {
fmt.Printf("提取到校验错误，字段：%s，信息：%sn", ve.Field, ve.Msg)
}
}
在上面的例子中，即使process返回的错误被文本包装，errors.As也能找到底层的*ValidationError并赋值给ve。传统类型断言err.(*ValidationError)在此场景会直接失败。
需要注意，target必须传指针的地址（如&ve），若传值或nil指针会导致panic。另外，如果错误链上有多个同类型错误，errors.As取最外层匹配项，这通常与调用顺序一致。
常见误用与注意事项
第一个常见误用是把errors.As的第二个参数写成错误值而非指针地址，例如errors.As(err, ve)，这会在运行时引发panic。正确写法是始终传入指向目标类型的指针变量地址。
第二个误区是混用errors.Is和errors.As：前者比较错误值是否相等，后者做类型匹配。若目标是一个具体类型实例而非变量，应使用As；若只是判断是否为某个预定义错误变量，使用Is即可。
package main
import (
"errors"
"fmt"
)
func badExample() {
err := errors.New("simple")
// 错误示范：第二个参数不是指针地址
// var e error
// errors.As(err, e) // panic
// 正确示范
var targetErr error
if errors.As(err, &targetErr) {
fmt.Println("提取成功", targetErr)
}
}
此外，自定义错误类型若想影响errors.Is的结果，可实现Is(error) bool方法；若想影响errors.As，只需保证自身类型可被赋值即可。不要过度包装错误，以免错误链过长影响可读性和性能。
在大型项目中，建议统一在底层定义 sentinel 错误和结构化错误类型，中层用%w包装补充上下文，上层用errors.Is与errors.As做分支处理，这样既能保留错误源头，又能让调用方精确响应。
与旧版错误处理方式的对比
在Go 1.13之前，开发者常通过字符串包含判断（如strings.Contains(err.Error(), "not found")）或类型断言来处理错误。字符串方式脆弱且受语言环境影响，类型断言则无法穿透包装错误。
下表简要对比三种方式在错误被包装时的表现：
| 处理方式 | 能否识别包装后的 sentinel 错误 | 能否提取自定义类型 | 稳定性 |
|---|---|---|---|
| 字符串比较 | 可能（依赖文本） | 否 | 低 |
| 类型断言 | 否 | 仅最外层 | 中 |
| errors.Is / As | 是 | 是（链上任意层） | 高 |
可以看出，标准库提供的两个函数从语言层面解决了错误链透传问题，是现行Go错误处理的推荐做法。新项目应直接使用它们，老项目可逐步将关键错误分支迁移过来。
最后，错误包装并非越多越好。仅在需要补充调用上下文时使用%w，避免把每一层都包装一遍，否则错误信息和链路会膨胀，反而干扰errors.Is与errors.As的精准度。