1. 基本概念与职责
1.1 错误包装与 unwrap 的关系
在 Go 语言中，错误可以通过包装来传递上下文信息，形成一个错误链。错误链的存在让调用方在不丢失原始错误的前提下获取更多上下文。unwrap/解包机制提供逐层抬升的能力，允许从外层包装逐步查找底层错误。
errors.Is和errors.As正是依赖于这个解包机制来检索目标错误的工具。当一个错误实现了 Unwrap() error，错误处理逻辑就可以通过重复解包来对比或提取信息。
1.2 errors.Is 的职责与行为
errors.Is用于判断一个错误链中是否存在与目标错误等价的错误。它的核心是遍历错误链并比较目标错误。若包装的错误类型实现了 Is(target error) bool，则会调用该方法来判断是否等价，这为自定义错误提供了灵活的匹配方式。
如果错误本身或其包装未实现 Is，errors.Is 会继续通过 Unwrap 逐层向下查找，直到找到等价的错误或链条结束。因此，错误包装和自定义 Is 行为共同决定匹配结果。
2. 使用场景对比
2.1 何时使用 errors.Is
使用场景一：你关心的是某个“哨兵错误”是否在错误链中出现。像 io.EOF、os.ErrNotExist等标准包中的哨兵错误，使用 errors.Is 可以在包装链中判断是否包含这些哨兵错误。
使用场景二：你自定义了一个错误类型或情况，并希望把“是否等价于某个目标错误”作为判断条件。通过为自定义错误实现 Is(target error) bool，errors.Is 能把匹配逻辑委托给自定义实现，提供灵活性。
2.2 何时使用 errors.As
使用场景三：你需要从错误链中提取具体的错误类型或接口信息，以便进一步处理。errors.As会在链中找到能赋值给目标类型的错误，并把该错误赋值给你提供的目标变量。
使用场景四：你知道可能的错误类型集合，比如 *os.PathError、*net.OpError 等等，使用 As 可以直接获得对应的具体类型，以便访问特定字段（如 Path、Op、Err 等）并据此做出针对性处理。
3. 实战代码示例
3.1 使用错误包装与 errors.Is
下面的例子展示了如何通过 fmt.Errorf 的 %w 进行错误包装，并使用 errors.Is 判断是否包含哨兵错误。
package mainimport ("errors""fmt"
)var ErrNotFound = errors.New("not found")func wrapNotFound() error {// 使用 %w 包装 ErrNotFound，形成错误链return fmt.Errorf("operation failed: %w", ErrNotFound)
}func main() {err := wrapNotFound()if errors.Is(err, ErrNotFound) {// 找到了 ErrNotFound 在错误链中的等价项println("Detected ErrNotFound via errors.Is")}
}
3.2 使用 errors.As 提取具体错误类型
下面的示例演示如何从错误链中提取一个具体的错误类型，例如 *os.PathError，以便读取其中的字段信息。
package mainimport ("errors""fmt""os"
)func openWrapper(name string) error {f, err := os.Open(name) // 可能返回 *os.PathErrorif err != nil {return fmt.Errorf("open failed: %w", err)}defer f.Close()return nil
}func main() {err := openWrapper("missing.txt")var pe *os.PathErrorif errors.As(err, &pe) {// 已从链中提取到 *os.PathError，可以访问 Path, Op, Errfmt.Printf("path: %s, op: %s, err: %v\n", pe.Path, pe.Op, pe.Err)} else {// 未在链中找到该错误类型fmt.Println("not a PathError in the chain")}
}
3.3 自定义错误类型与 Is/As 的协作示例
通过自定义错误类型并可选性实现 Is，可以定义更灵活的等价判定。下面的示例展示了一个自定义错误类型和 Is 的用法。
package mainimport ("errors""fmt"
)type MyError struct {Code intMsg string
}func (e *MyError) Error() string { return e.Msg }// 可选：自定义 Is 行为，允许按 Code 匹配
func (e *MyError) Is(target error) bool {t, ok := target.(*MyError)if !ok {return false}return e.Code == t.Code
}func produce() error {return &MyError{Code: 404, Msg: "resource not found"}
}func main() {err := produce()// 使用 As 提取具体类型信息var me *MyErrorif errors.As(err, &me) {fmt.Println("error code:", me.Code) // 404}// 使用 Is 进行等价判断（依赖实现的 Is）var sentinel = &MyError{Code: 404}if errors.Is(err, sentinel) {fmt.Println("matched via Is with custom error type")}
}
4. 实际注意点
4.1 匹配自定义错误的 Is 行为
当错误链中包含自定义错误类型时，Is的实现会影响匹配结果。如果自定义错误实现了 Is(target error) bool，请确保其行为符合你在使用 errors.Is 时的期望，否则可能导致匹配失败。
此外，errors.As与 Is 的工作重点不同：As专注于“能否赋值为目标类型”，而不是“是否等价于目标错误”。在复杂的包装场景中，两个方法往往互补使用。
4.2 与错误包装链的兼容性
无论你是简单地使用 fmt.Errorf 的 %w 包装，还是自定义包装结构，errors.Is和errors.As都会沿着错误链进行解包查找。只要链中存在可识别的底层错误，两个 API 都有机会发挥作用。
需要注意的是，Unwrap的实现决定了链的深度和可见性。如果某些包装没有实现 Unwrap()，那么错误链就会被截断，Is/As 的检索能力也会随之受限。
