errors.as 不能用 == 判断错误类型，因其需通过 unwrap() 逐层解包匹配具体类型指针；目标变量必须为对应错误类型的指针，否则静默失败；仅当需访问错误字段时才应使用，存在性判断优先用 errors.is。
Errors.As 为什么不能直接用 == 判断错误类型
因为 Go 的 error 是接口，底层值可能是任意具体类型，== 只比较接口的动态值（即指针或字面量），对自定义错误或包装错误几乎总返回 false。比如 fmt.Errorf("wrap: %w", io.EOF) 和原始 io.EOF 用 == 对比结果是 false，但业务上你很可能需要识别出它“本质是 EOF”。
-
Errors.As会逐层解包错误（调用Unwrap()），直到找到匹配的目标类型或返回false - 只适用于实现了
Unwrap() error方法的错误（如fmt.Errorf包装、errors.Join、errors.WithStack等） - 如果错误链里有多个同类型错误，
As只返回第一个匹配的，不会继续向下找
如何正确声明目标变量并调用 Errors.As
目标变量必须是指针类型，且类型要和你想提取的错误具体类型完全一致 —— 这是最常踩的坑。传入非指针、类型不匹配、或用 *error 都会静默失败（返回 false，且目标变量不变）。
- ✅ 正确写法：
var e *os.PathError; if errors.As(err, &e) { ... } - ❌ 错误写法：
var e os.PathError; errors.As(err, &e)（e是值类型，&e是*os.PathError，但As要求目标本身是指针类型变量） - ❌ 错误写法：
var e *error; errors.As(err, &e)（*error是指向接口的指针，不是具体错误类型的指针） - 如果不确定错误是否可解包，先用
errors.Is做粗筛，再用As提取细节
常见错误类型提取场景与对应目标类型
不同标准库错误需配对正确的指针类型，否则 As 总是失败。尤其注意：有些错误类型在不同 Go 版本中路径或结构有变化（如 Go 1.20+ 的 net.OpError 字段更细）。
- 想判断是否是文件路径错误：
var e *os.PathError - 想获取网络操作错误详情：
var e *net.OpError - 想检查是否是超时错误（含
context.DeadlineExceeded或底层超时）：var e *os.SyscallError（部分系统）或更稳妥地用errors.Is(err, context.DeadlineExceeded) - 自定义错误（如
type MyErr struct{ Code int }）必须实现Unwrap() error才能被As向下穿透
性能和嵌套深度的实际影响
Errors.As 不是零成本操作：它会递归调用 Unwrap()，每层都是一次接口动态调用。错误链越深、Unwrap() 实现越重（比如带堆栈追踪的错误），开销越大。
立即学习“go语言免费学习笔记（深入）”；
- 单次调用通常可忽略，但在 hot path（如高并发 HTTP 中间件）里频繁使用需警惕
- Go 默认不限制解包深度，但循环错误（A 包 B，B 包 A）会导致 panic；生产环境建议用
errors.Is替代深层As做存在性判断 - 如果只需要知道“是不是某类错误”，优先用
errors.Is(err, target)；只有需要访问该错误的具体字段（如e.Path,e.Err）时，才用As
真正难的不是写对那行 errors.As(err, &e)，而是想清楚：这个错误链里，哪一层的字段你非读不可？有没有可能上游已经把关键信息提到了外层错误里？别让 As 成为默认动作。
