errors.As 不能直接断言底层错误类型，因其依赖 Unwrap 方法递归查找，若错误链中某层未实现 Unwrap 或使用不兼容包装器（如旧版 pkg/errors），则查找中断；且仅返回第一个匹配的 *T 类型实例，接收变量必须为 &t 形式。
errors.As 为什么不能直接断言底层错误类型
errors.As 的设计目标是安全地从错误链中提取特定类型的错误值，但它不会穿透所有包装器——比如某些自定义错误或第三方库（如 github.com/pkg/errors 旧版）可能未实现 Unwrap 方法，或只返回 nil。此时 errors.As 查找不到匹配项，即使错误值实际包含目标类型。
-
标准库的
fmt.Errorf（带%w）和errors.Join返回的错误支持多层Unwrap，errors.As能递归查找 - 但像
errors.New("xxx")或手动实现的错误类型若没提供Unwrap() error方法，errors.As就止步于该层 - 如果错误链中存在多个同类型实例，
errors.As只返回第一个匹配到的
如何正确使用 errors.As 提取 *os.PathError
常见场景是判断文件操作失败是否由路径不存在导致，需提取 *os.PathError 并检查其 Err 字段。注意：不能直接对原始错误做类型断言，必须用 errors.As 配合指针接收变量。
var pathErr *os.PathError
if errors.As(err, &pathErr) {
if os.IsNotExist(pathErr.Err) {
// 处理文件或目录不存在
}
}
- 第二个参数必须是
*T类型的地址（如&pathErr），不是pathErr本身 - 如果传入
pathErr（值类型），errors.As无法写入目标变量，永远返回false -
*os.PathError是具体类型，不可用接口如error替代接收
errors.As 与 errors.Is 的关键区别
errors.Is 判断错误链中是否存在某个**值相等**的错误（常用于 os.IsNotExist 这类包装过的哨兵错误），而 errors.As 是提取**类型匹配**的具体错误实例。两者目的不同，不可混用。
-
errors.Is(err, os.ErrNotExist)→ 检查是否等于哨兵错误（底层调用Is()方法） -
errors.As(err, &pathErr)→ 把错误链中第一个*os.PathError实例赋给pathErr - 若想同时判断类型和值，需先
As提取，再对其Err字段调用errors.Is
自定义错误类型要支持 errors.As 必须实现 Unwrap
如果你的错误类型被包装在其他错误中（例如用 fmt.Errorf("failed: %w", myErr)），而希望上层能用 errors.As 提取它，就必须让该类型实现 Unwrap() error 方法。
立即学习“go语言免费学习笔记（深入）”；
type MyError struct {
Msg string
Code int
}
func (e *MyError) Error() string { return e.Msg }
func (e *MyError) Unwrap() error { return nil } // 返回 nil 表示无下一层
- 返回
nil是合法的，表示它是错误链末端；返回另一个error才会继续递归 - 如果忘记实现
Unwrap，errors.As在遇到该错误时就停止遍历，无法提取其下游嵌套的类型 - 不要返回自身（如
return e），会导致无限递归 panic
pkg/errors 的 Wrap），errors.As 就可能失效——这时候得靠日志或 fmt.Printf("%+v", err) 看展开结构，再决定是否要加一层手动解包逻辑。 
