errors.as第二个参数必须是& e，因为它是值传递语言，需通过指针将匹配到的错误实例写入目标变量；传e或* t会导致类型不匹配、编译错误或panic。
errors.As 不是类型断言语法糖，它必须传入目标类型的指针变量地址，否则无法写入、必然失败。
errors.As 第二个参数为什么必须是 &e 而不是 e 或 *T
因为 errors.As 需要将匹配到的错误实例“写入”你提供的变量。Go 是值传递语言，只有传入指针才能修改原变量内容。
-
var e *os.PathError; errors.As(err, &e)✅ 正确：&e类型是**os.PathError，errors.As可以把找到的*os.PathError赋值给e -
errors.As(err, e)❌ 编译报错：不能把*os.PathError当作interface{}传入 -
errors.As(err, (*os.PathError)(nil))❌ 运行时 panic：nil 指针无法写入 -
errors.As(err, &os.PathError{})❌ 无效：临时结构体不可寻址，且类型不匹配（目标应为*os.PathError的地址，而非os.PathError的地址）
提取 *net.OpError 或自定义错误时常见类型不匹配
标准库中多数错误类型（如 net.OpError、os.PathError、url.Error）在返回时都是指针形式，但 errors.As 匹配的是“能赋值给目标类型”的错误，不是“名字像就行”。
- 正确写法：
var opErr *net.OpError; if errors.As(err, &opErr) { opErr.Timeout() } - 错误写法：
var opErr net.OpError; errors.As(err, &opErr)→ 即使错误链里有*net.OpError，也无法赋值给net.OpError值类型 - 自定义错误同理：若定义了
type MyErr struct{ Code int }，就必须用var e *MyErr，而不是var e MyErr - 接口类型例外：若想判断是否实现了某个接口（如
interface{ Timeout() bool }），需声明该接口变量指针：var timeouter interface{ Timeout() bool }; errors.As(err, &timeouter)
为什么 errors.As 找不到深层错误？错误链可能已断裂
errors.As 只沿 Unwrap() 链单向查找第一个匹配项。如果中间某层错误没实现 Unwrap()，或用了 %v 替代 %w，链就断了，后续错误不可达。
-
fmt.Errorf("wrap: %v", err)→Unwrap()返回nil，链在此终止 -
fmt.Errorf("wrap: %w", errors.New("raw"))→errors.New不含Unwrap()方法，下一层无法展开 -
errors.Join(err1, err2)返回的错误支持多路Unwrap()，但errors.As仍只取第一个成功匹配的分支，不会遍历全部 - 第三方包（如旧版
pkg/errors）未适配标准Unwrap()接口，也会导致errors.As失效
别忽略返回值，匹配失败时目标变量保持原值
errors.As 返回 bool 表示是否成功赋值。它不会清空或重置你声明的变量 —— 若匹配失败，e 仍是零值（如 nil）或上一次的旧值。
- 直接使用未检查返回值的
e可能引发 panic（如调用e.Path时e == nil） - 复用同一变量多次调用
errors.As是安全的，但每次都要检查返回值：if errors.As(err, &e) { /* use e */ } - 不要写成
if errors.As(err, &e) { } else { /* assume e is valid */ }——else分支里e并未被赋值
最易被忽略的点是：errors.As 不关心错误语义，只做类型匹配；它也不保证线程安全——多个 goroutine 同时对同一个 err 调用 errors.As 并写入同一变量 &e，结果取决于执行顺序。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
