errors.As 总是返回 false 的根本原因是第二个参数必须是指向接口变量的指针，而非错误值指针或字面量地址；正确用法为 var target *os.PathError; errors.As(err, &target)。
errors.As 为什么总是返回 false
常见现象是 errors.As 判断失败，哪怕错误链里明明包含目标类型。根本原因不是代码写错了，而是传入的第二个参数必须是指针——不是指向错误值的指针，而是「指向接口变量的指针」。
正确用法：var target *os.PathError; if errors.As(err, &target) { ... }。如果写成 errors.As(err, target) 或 errors.As(err, &os.PathError{})，都会失败。
- 必须声明一个具体类型的变量（如
*os.PathError），再取它的地址传给errors.As - 不能传临时结构体字面量的地址，因为 Go 不允许取字面量的地址
- 如果错误是包装过的（比如用
fmt.Errorf("wrap: %w", err)），errors.As会自动解包，但只解一层%w；嵌套多层时仍能命中，前提是路径上每层都用了%w
什么时候该用 errors.As 而不是 type assertion
直接类型断言（err.(*os.PathError)）只能判断错误是否「恰好是」某个具体类型，无法处理包装错误。而 errors.As 是为错误链设计的：只要错误链中任意一层是目标类型（或实现了目标接口），就能匹配成功。
典型场景：HTTP handler 中统一捕获文件系统错误，不管它是从 os.Open 直接返回，还是被中间件用 fmt.Errorf("failed to serve asset: %w", err) 包了一层。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
errors.As：需要穿透包装、兼容多种错误来源、面向接口编程（比如检查是否实现了Temporary() bool方法） - 用类型断言：确定错误来源单一、不涉及包装、且你明确知道它就是那个具体类型
- 注意：如果目标类型是接口（如
interface{ Timeout() bool }），errors.As同样支持，但变量声明得是该接口的指针：var timeouter interface{ Timeout() bool }; errors.As(err, &timeouter)
errors.As 和 errors.Is 的关键区别
errors.Is 检查的是错误的「语义相等性」，比如是否等于某个预定义的哨兵错误（io.EOF）；而 errors.As 检查的是「类型可转换性」，关注结构和行为。
一个常见误用是：想判断是否是网络超时错误，却写了 errors.As(err, &net.OpError{}) ——这会失败，因为 net.OpError 是具体结构体，但实际返回的往往是它的指针 *net.OpError。应该声明 *net.OpError 变量。
-
errors.Is(err, io.EOF)→ 判断是否等于哨兵值 -
errors.As(err, &e)其中e *net.OpError→ 判断能否提取出该类型实例 - 两者可以组合使用：先
errors.As提取出*net.OpError，再调用e.Timeout()做进一步判断
自定义错误类型怎么配合 errors.As 使用
只要你的错误类型实现了 Unwrap() error 方法（返回内部错误），它就能被 errors.As 正确解包。不需要额外实现其他接口。
示例：一个带重试次数的包装错误：
type RetryError struct {
Err error
Try int
}
func (e *RetryError) Unwrap() error { return e.Err }
这样写后，errors.As(wrappedErr, &target) 就能从 *RetryError 里解出底层的 *os.PathError。
- 如果不想暴露内部错误（比如出于安全考虑），就不要实现
Unwrap——此时errors.As会在这一层停止解包 - 多个
Unwrap返回非 nil 错误也没问题，errors.As会按深度优先遍历整条链 - 注意循环引用：如果
A.Unwrap()返回B，而B.Unwrap()又返回A，errors.As会 panic
