errors.As 总是返回 false 的最常见原因是目标变量未传入指针，或错误链中不存在匹配的底层错误类型；它通过逐层调用 Unwrap() 进行类型匹配，需传入指向接口或具体类型的指针（如 &myErr），且自定义错误必须实现 Unwrap() 方法。
errors.As 为什么总是返回 false
errors.As 返回 false 的最常见原因是：目标变量未传入指针，或错误链中根本不存在匹配的底层错误类型。它不是类型断言（err.(*MyError)），而是沿着错误链逐层调用 Unwrap()，对每个包装层做类型匹配——只要任意一层的底层错误能被赋值给目标指针所指向的类型，就返回 true。
实操要点：
- 必须传入 指向接口或具体类型的指针，例如
&myErr，而非myErr - 目标类型需是接口或结构体指针；若用值类型（如
MyError）会导致编译失败 - 如果错误由
fmt.Errorf("...: %w", err)包装，且err是目标类型，则errors.As能命中；但若用fmt.Errorf("...")无%w，则断链，无法向下查找 - 自定义错误类型必须实现
Unwrap() error方法才能参与链式查找
如何正确声明目标变量配合 errors.As
目标变量必须在调用前声明，并传其地址。Go 不允许在 errors.As 调用中直接声明新变量（比如 errors.As(err, &newErr) 中 newErr 未预先声明会报错）。
推荐写法：
立即学习“go语言免费学习笔记（深入）”；
var myErr *os.PathError
if errors.As(err, &myErr) {
log.Println("path error:", myErr.Path)
}
常见错误写法（编译失败）：
if errors.As(err, &var myErr *os.PathError) { ... } // 语法错误
if errors.As(err, new(MyError)) { ... } // new 返回 *MyError，但类型不匹配或不可寻址
注意事项：
- 若不确定错误是否为某类型，先声明零值变量再传地址，避免 panic
- 可复用同一变量多次调用
errors.As，但每次调用前无需清空——匹配成功才会写入 - 对接口类型（如
interface{ Timeout() bool }），需声明对应接口变量指针：var timeoutErr interface{ Timeout() bool }，再传&timeoutErr
errors.As 和 errors.Is 的关键区别
errors.As 解决“这个错误是不是某种具体类型”，用于提取错误上下文；errors.Is 解决“这个错误链里是否包含某个特定错误值”，用于语义相等判断（如是否等于 os.ErrNotExist）。
典型误用场景：
- 想判断是否是网络超时错误，却用
errors.As(err, &net.OpError{})——应改用errors.As(err, &opErr)并检查opErr.Timeout()，或直接用errors.Is(err, context.DeadlineExceeded) - 用
errors.Is(err, os.ErrNotExist)正确；但用errors.As(err, &os.ErrNotExist)错误——因为os.ErrNotExist是变量，不是类型 -
errors.Is可匹配未导出的底层错误值（如标准库内部错误），errors.As则必须有公开可实例化的类型
自定义错误类型要支持 errors.As 必须满足什么条件
仅实现 Error() string 不够。errors.As 要遍历错误链，必须能调用 Unwrap() 向下传递。因此自定义错误若希望被 errors.As 正确识别，需显式提供 Unwrap() 方法并返回包装的底层错误。
type MyAPIError struct {
Code int
Err error
}
func (e *MyAPIError) Error() string { return fmt.Sprintf("API error %d", e.Code) }
func (e *MyAPIError) Unwrap() error { return e.Err } // 必须有这一行
否则，当 err = &MyAPIError{Code: 500, Err: os.ErrPermission} 时，errors.As(err, &permErr) 会失败，因为无法解包到 os.ErrPermission。
补充提醒：
- 如果错误不包装其他错误（即叶子节点），
Unwrap()应返回nil - 多个嵌套层级时，每层都需实现
Unwrap()，否则链在该层中断 - 使用
xerrors或旧版github.com/pkg/errors的代码可能依赖不同行为，迁移到标准库errors时需重审Unwrap实现
最容易被忽略的是：哪怕只用标准库，只要自己写了包装错误，就绕不开 Unwrap——不实现，As 就看不见里面的东西。
