应使用 errors.as 而非裸类型断言来安全识别特定错误类型，因 errors.as 可逐层解包嵌套错误，而裸断言易 panic 且不支持包装；自定义错误需实现 unwrap() 和/或 is() 方法以兼容。
如何用类型断言判断错误是否为特定错误类型
Go 中的 error 是接口，底层可能是任意实现了 Error() string 方法的类型。直接用 == 比较两个 error 值通常无效（除非是同一个指针或预定义的导出错误变量），必须通过类型断言或 errors.As 来识别具体类型。
最常用且安全的方式是使用 errors.As，它能正确处理嵌套错误（比如被 fmt.Errorf("...: %w", err) 包装过的错误）：
var pathError *fs.PathError
if errors.As(err, &pathError) {
log.Printf("文件路径错误：%s", pathError.Path)
}
-
errors.As会逐层解包错误链，找到第一个匹配目标类型的错误 - 第二个参数必须是指向目标错误类型的指针（如
&pathError），不能传值 - 如果只是判断是否为某个已知变量（如
io.EOF），可用errors.Is(err, io.EOF)
为什么不能直接用类型断言 err.(*fs.PathError)
裸类型断言在运行时 panic 的风险很高——一旦 err 不是该类型或为 nil，程序就崩溃。尤其在错误被包装后（如 fmt.Errorf("read failed: %w", err)），原始类型信息已被隐藏，断言必然失败。
正确写法是带 ok 判断的类型断言，但仅适用于**未被包装**、且你 100% 确认错误来源的场景：
立即学习“go语言免费学习笔记（深入）”；
if pathErr, ok := err.(*fs.PathError); ok {
// 安全使用 pathErr
}
- 这种写法不处理嵌套，
fmt.Errorf("wrap: %w", &fs.PathError{})会导致ok == false - 多数标准库错误（如
os.IsNotExist）内部其实也依赖errors.As或类似逻辑 - 自定义错误若想支持
errors.As，需确保其字段可寻址（即不能是 unexported 字段嵌套在不可寻址结构中）
自定义错误类型如何支持 errors.As 和 errors.Is
要让自定义错误能被 errors.As 正确识别，只需保证它本身是目标类型，或实现 Unwrap() error 方法返回下一层错误；而 errors.Is 要求错误满足「相等性语义」，通常靠实现 Is(error) bool 方法。
type MyTimeoutError struct{ msg string }
func (e *MyTimeoutError) Error() string { return e.msg }
func (e *MyTimeoutError) Is(target error) bool {
_, ok := target.(*MyTimeoutError)
return ok
}
- 注意：
Is方法接收的是error接口，需做类型断言判断是否为同一类型 - 如果错误包含状态码等可比字段，
Is可进一步比较字段值（如e.Code == targetCode） - 若错误被包装，记得在
Unwrap()中返回内层错误，否则errors.As无法穿透
常见误判场景和调试建议
线上遇到“明明是超时错误却进不了 errors.As 分支”，大概率是错误被多层包装后类型丢失，或自定义错误没实现 Unwrap。
- 用
fmt.Printf("%+v", err)查看错误全貌，确认是否含unwrapped或caused by字样 - 检查是否混用了
errors.New（不支持包装）和fmt.Errorf（支持%w） - 标准库中
net.OpError、os.SyscallError都支持errors.As，但它们的字段名和嵌套深度容易让人误判目标类型 - 第三方库（如
github.com/pkg/errors）旧版本不兼容errors.As，需升级或改用标准库fmt.Errorf
类型断言不是语法糖，它是错误分类的基础设施；写错一层 Unwrap 或漏掉一个 &，就可能让整个错误处理逻辑静默失效。
