errors.as 不能直接用 == 比较错误，因为 go 的 error 是接口类型，不同实例即使内容相同底层指针也不同；它通过遍历错误链尝试类型断言，需传目标类型的指针，仅匹配第一层可转换的包装，不自动穿透多层包装。
errors.As 为什么不能直接用 == 比较错误
Go 的错误是接口类型，error，不同函数返回的错误即使内容相同，底层指针也不同。用 == 判断会失败，比如 os.Open("missing.txt") 返回的 *os.PathError 和你手动 new 的同类型错误不相等。
真正要判断的是“这个错误是否由某种具体错误类型包装而来”，errors.As 就是干这个的：它沿着错误链（wrapping chain）向下查找，看能否把某个错误值赋给目标类型的变量。
- 必须传入一个指向目标类型的指针，比如
&targetErr，不是targetErr - 只匹配第一个能成功转换的包装层，不会跳过中间层找更深层的原始错误
- 如果错误链里有多个包装，但只有最外层是
*os.PathError，而你想匹配内层的syscall.Errno，errors.As默认找不到——得靠errors.Unwrap或循环调用
errors.As 的典型用法和参数陷阱
常见写法是先声明一个目标错误变量，再传它的地址：
var pathErr *os.PathError
if errors.As(err, &pathErr) {
fmt.Println("文件路径问题:", pathErr.Path)
}
注意三点：
-
errors.As第二个参数必须是*T类型，且T必须是接口或指针类型（不能是基础类型如int） - 如果传了
nil指针（比如var p *os.PathError; errors.As(err, p)），会 panic - 目标变量在调用前不需要初始化，
errors.As会负责赋值；但如果类型不匹配，变量保持原值（通常是 nil）
和 errors.Is 的区别：什么时候该用哪个
errors.Is 判断错误链中是否存在某个**具体值**（比如 os.ErrNotExist），适合检查预定义的哨兵错误；errors.As 判断是否能转成某个**类型**，适合提取结构体字段或调用方法。
- 想确认是不是“文件不存在”？用
errors.Is(err, os.ErrNotExist) - 想拿到
*os.PathError里的Path字段？必须用errors.As(err, &pathErr) - 如果既想判断类型又想检查值，比如确认是
*os.PathError且Err是syscall.ENOENT，得组合用：errors.As(err, &pathErr) && errors.Is(pathErr.Err, syscall.ENOENT)
嵌套错误太多时容易漏掉深层类型
Go 1.13+ 支持错误包装（fmt.Errorf("wrap: %w", err)），但 errors.As 默认只查一层。如果错误被多层包装（比如 A → B → C），而你要的是 C 类型，errors.As 可能失败。
这时有两个选择：
- 手动循环
errors.Unwrap直到 nil，每层都试errors.As - 用第三方库如
github.com/pkg/errors的errors.Cause（但标准库不推荐依赖它） - 更稳妥的做法：写个辅助函数，封装递归查找逻辑，避免每次重复写 unwrap 循环
标准库没提供“深度 As”，这点容易被忽略——以为一次调用就能穿透所有包装层。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
