errors.Is 返回 false 是因只用 == 比较错误值而非消息，需复用同一错误变量；errors.As 需传指针地址 &perr 且被包装错误须可赋值给目标类型；仅 %w 保留包装链，%v 会断链；nil 错误下二者恒返回 false。
Go 1.13 引入的 errors.Is 和 errors.As 是处理包装错误（wrapped errors）的官方标准方式，取代了过去用字符串匹配或类型断言的脆弱做法。它们能正确穿透多层 fmt.Errorf("...: %w", err) 包装链，但用错场景或忽略细节极易失效。
为什么 errors.Is 有时返回 false，即使错误看起来“相等”？
errors.Is 判断的是「错误链中是否存在某个目标错误值」，不是比较错误消息或类型是否一致。它只对实现了 Unwrap() error 方法的错误才递归检查，且最终比对使用 ==（即指针或可比较值的直接相等）。
- 若你用
errors.New("timeout")创建目标错误，但被包装的原始错误是另一个errors.New("timeout")实例，则errors.Is(err, errors.New("timeout"))一定为false—— 因为两个*errors.errorString指针不同 - 正确做法是复用同一个错误变量：
var ErrTimeout = errors.New("timeout") ... err := fmt.Errorf("failed to connect: %w", ErrTimeout) if errors.Is(err, ErrTimeout) { ... } // ✅ true - 自定义错误类型若想被
errors.Is正确识别，需在Is()方法中显式支持（例如匹配底层状态码），而不仅依赖Unwrap()
errors.As 为何无法从包装链中提取 *os.PathError？
errors.As 的作用是「尝试将错误链中的任意一层转换为目标类型指针」，但它要求目标必须是指针类型，且被包装的错误本身（或某层 Unwrap() 返回值）能被赋值给该指针指向的类型。
- 常见错误写法：
var perr *os.PathError if errors.As(err, perr) { ... } // ❌ perr 是 nil 指针，As 无处写入 - 正确写法是传入指针的地址：
var perr *os.PathError if errors.As(err, &perr) { // ✅ &perr 是 **os.PathError log.Println("path:", perr.Path) } - 如果错误链中某层是
*os.SyscallError，而你试图As成*os.PathError，仍会失败——二者无类型继承关系，As不做类型转换，只做安全的类型断言 + 解包穿透
包装错误时，%w 和 %v 的选择直接影响 errors.Is/As 是否可用
只有用 %w 才会调用被格式化错误的 Unwrap() 方法并建立包装关系；用 %v、%s 或字符串拼接只是把错误转成字符串，彻底切断错误链。
- 错误示例（链断裂）：
err := os.Open("missing.txt") err = fmt.Errorf("open config: %v", err) // ❌ 字符串化，Unwrap() 不再被调用 - 正确示例（链保持）：
err := os.Open("missing.txt") err = fmt.Errorf("open config: %w", err) // ✅ 可被 Is/As 穿透 - 注意：若被包装错误本身不实现
Unwrap()（如老版本第三方错误、自定义错误未实现），%w也无效——此时errors.Is和errors.As都只能看到最外层错误
最容易被忽略的一点：errors.Is 和 errors.As 对 nil 错误有特殊处理——errors.Is(nil, someErr) 恒为 false，errors.As(nil, &target) 恒为 false。别忘了在调用前检查原始错误是否为 nil。
