errors.As 总是返回 false 的根本原因是第二个参数必须是指向接口变量的指针（如 &e），而非错误值指针或 nil 指针；它只匹配错误链中第一个符合条件的错误，且依赖正确实现的 Unwrap() 方法。
errors.As 为什么总是返回 false
常见现象是 errors.As 判断失败，明明错误链里有目标类型，却拿不到。根本原因不是用法错，而是传入的第二个参数必须是指针——不是指向错误值的指针，而是「指向接口变量的指针」。
- 正确写法：
var e *os.PathError; errors.As(err, &e)——&e是*(*os.PathError)类型 - 错误写法：
errors.As(err, e)或errors.As(err, (*os.PathError)(nil))，前者类型不匹配，后者是 nil 指针，无法写入 - 如果目标类型是自定义错误（比如
type MyErr struct{...}），也得声明var e *MyErr，再传&e - 注意：
errors.As只检查错误链中「第一个匹配的」，不会跳过中间包装器；若中间有fmt.Errorf("wrap: %w", err)但没实现Unwrap()，那后面的错误就断了
errors.As 和 errors.Is 的核心区别在哪
errors.Is 查的是「错误值是否等于某个目标值或其包装链中的某个值」，适合判断错误码、哨兵错误（如 io.EOF）；errors.As 查的是「能否把错误链中某个错误转成指定类型」，用于提取上下文信息（比如路径、超时时间、HTTP 状态码）。
-
errors.Is(err, io.EOF)→ 判断是不是 EOF 错误（或被它包装） -
var e *os.PathError; errors.As(err, &e)→ 把底层os.PathError提出来，访问e.Path或e.Err - 两者不互斥：可以先
errors.Is快速分类，再用errors.As提取细节 - 性能上，
errors.Is更轻量；errors.As需要反射类型检查，但日常使用无感
嵌套错误里有多个同类型错误，errors.As 只拿到第一个
这是设计使然，errors.As 不会遍历全部嵌套层级找所有匹配项，只返回错误链中「最靠近原始错误的那个」匹配实例。如果你需要所有 *os.PathError，就得手动遍历。
- 标准库没提供「全量提取」函数，得自己写循环：
for err != nil { if e, ok := err.(*os.PathError); ok { /* 处理 e */ }; err = errors.Unwrap(err) } - 注意：不能直接对
err做类型断言（err.(*os.PathError)），因为外部可能是fmt.Errorf包装，必须靠errors.As或手动Unwrap - 某些第三方包（如
pkg/errors旧版）的嵌套方式不兼容标准Unwrap()，会导致errors.As找不到深层错误
Go 1.13+ 的 errors.As 在 HTTP handler 中怎么安全用
Web 服务里常见把数据库错误、IO 错误层层包装后返回 500，但你想区分是「记录不存在」还是「连接超时」来返回不同状态码，这时 errors.As 就很关键。
立即学习“go语言免费学习笔记（深入）”；
- 别在 handler 里直接
http.Error(w, err.Error(), http.StatusInternalServerError)—— 丢失类型信息 - 推荐模式：先
errors.As(err, &e)尝试转成已知错误类型，再根据类型决定 status code 和响应体 - 示例：
if errors.As(err, &e) && e.Timeout() { http.Error(w, "timeout", http.StatusGatewayTimeout) } - 容易漏的一点：自定义错误类型必须导出方法（如
Timeout() bool），否则外部包调用不了；且方法不能依赖未导出字段，否则反射可能失败
最常卡住人的地方，是记混了 &e 和 e 的含义，以及默认认为错误链是扁平的——其实只要中间有个没实现 Unwrap() 的包装，后面就全断了。
