应使用 errors.Is 判断底层错误类型，因其能递归遍历 %w 包装的错误链；用 errors.As 提取包装错误中的具体值；避免字符串匹配和裸指针比较；确保全程使用 %w 保持错误链完整。
直接用 errors.Is 判断底层错误类型，别用 == 或 strings.Contains
Go 的错误链（error chain）让 err == io.EOF 失效，因为包装后的错误不再是同一个指针。常见误写是：if err == io.EOF 或 strings.Contains(err.Error(), "EOF") —— 前者在 fmt.Errorf("read failed: %w", io.EOF) 下永远为 false，后者脆弱且无法处理多语言错误信息。
正确做法始终用 errors.Is：
if errors.Is(err, io.EOF) {
// 处理 EOF
}
它会递归遍历 %w 包装的错误链，安全可靠。同理，自定义错误也应实现 Unwrap() 方法以支持该机制。
用 errors.As 提取具体错误值，而不是类型断言嵌套
当需要访问包装错误中的原始结构体字段（比如 *os.PathError 的 Path 字段），很多人写成：if e, ok := err.(*os.PathError); ok { ... } —— 这在错误被包装后必然失败。
errors.As 是专为此设计的：
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("failed on path: %s", pathErr.Path)
}
它同样遍历错误链，找到第一个匹配类型的错误并赋值。注意传入的是指针地址，不是值；且目标变量必须是指针类型（如 *os.PathError）。
避免在 defer 中重复检查同一 err 变量
典型反模式：defer func() { if err != nil { log.Println(err) } }()，但函数内又多次对 err 赋值并检查，导致日志重复或掩盖真实错误源。
