Golang 中 error 包装 errors.Is 与 errors.As-Golang-PHP中文网

err == io.EOF 总是 false 是因为该操作仅比较外层错误值，而实际错误常被 fmt.Errorf("xxx: %w", io.EOF) 多层包装，需用 errors.Is(err, io.EOF) 逐层 Unwrap() 查找；必须全程使用 %w 包装，目标错误须为导出变量（如 io.EOF），不可临时构造。

errors.Is 为什么 err == io.EOF 总是 false

因为 err == io.eof 只比较最外层错误的指针或值，而实际错误往往被 fmt.errorf("xxx: %w", io.eof) 多层包装过，外层是 *fmt.wraperror 类型，和 io.eof 根本不相等。

正确做法是用 errors.Is(err, io.EOF)——它会逐层调用 Unwrap()，直到某一层返回的错误值等于 io.EOF（即同一变量地址）。

必须用 %w 包装，%v 或字符串拼接会截断错误链
目标错误必须是可比较的：标准库导出变量（如 os.ErrNotExist）、包级变量（如 var ErrTimeout = errors.New("timeout")），不能每次 errors.Is(err, errors.New("xxx"))
errors.Is(err, nil) 恒为 false，判空仍要用 err == nil

errors.As 提取 *os.PathError 失败的常见原因

写 errors.As(err, &pathErr) 却拿不到 Path 字段，大概率不是函数用错了，而是传参或错误链本身有问题。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

第二个参数必须是指针：&pathErr，不能是 pathErr 或 *pathErr
被包装的错误链中必须真有 *os.PathError 实例；如果中间某层用了 errors.New 或没实现 Unwrap() 的自定义错误，链就断了，As 查不到
匹配成功后才可安全访问字段，必须检查返回值：if errors.As(err, &pathErr) { log.Println(pathErr.Path) }，否则 pathErr 是零值，可能 panic
As 找到的是错误链中最内层（最早被包装）的那个匹配类型，不是最外层

自定义错误类型如何支持 errors.Is 和 errors.As

光实现 Error() string 不够。要让 errors.Is 和 errors.As 能穿透你的错误并识别/提取，必须主动参与标准错误链协议。

若只是终端错误（不包裹其他错误），无需额外操作，但也不能被 %w 包裹后还期望被解包
若要包装另一个错误，必须实现 Unwrap() error 方法，并返回那个被包裹的错误（哪怕它是 nil）
若希望 errors.Is 支持自定义逻辑（比如按状态码匹配），需实现 Is(target error) bool 方法
若希望 errors.As 支持更灵活的类型匹配（比如把 *MyError 当作 errorWithCode 接口提取），需实现 As(interface{}) bool 方法