Go如何判断io错误类型

Go 中判断 IO 错误应使用 errors.Is 和 errors.As：errors.Is 用于匹配哨兵值（如 fs.ErrNotExist、io.EOF），errors.As 用于安全断言具体类型（如 os.PathError、net.OpError），二者可穿透错误包装，避免字符串匹配或直接比较。

Go 中判断一个 error 是否是 IO 错误，不能靠字符串匹配或简单比较，而要依靠标准库提供的类型断言和错误分类工具——核心是 errors.Is 和 errors.As，配合 *os.PathError、*os.SyscallError、fs.ErrNotExist 等具体类型或哨兵值。

用 errors.As 判断是否为特定 IO 错误类型

IO 错误通常以指针形式返回（如 *os.PathError），所以要用 errors.As 进行安全类型断言：

• var pathErr *os.PathError，然后 if errors.As(err, &pathErr) { ... } 可提取路径、操作名、底层系统错误等信息
• var sysErr *os.SyscallError，适用于底层 syscall 失败（如 connect: connection refused）
• var pe *net.OpError，常见于网络 IO（如 dial timeout、read deadline exceeded）

用 errors.Is 判断是否属于某类 IO 哨兵错误

标准库预定义了一批可复用的哨兵错误，适合做语义判断：

• errors.Is(err, fs.ErrNotExist) → 文件/目录不存在（比 os.IsNotExist(err) 更推荐）
• errors.Is(err, io.EOF) → 读取到流末尾（注意：这不是异常，是正常终止信号）
• errors.Is(err, os.ErrPermission) → 权限不足
• errors.Is(err, os.ErrExist) → 文件已存在（常用于 os.Create 冲突）

区分“IO错误”和“非IO错误”的实用边界

不是所有带 io. 或 os. 前缀的 error 都算“IO错误”；关键看它是否源于系统调用或文件描述符操作：

• ✅ 属于 IO 错误：os.Open、file.Read、os.Stat、http.Get（底层 TCP 连接）、json.Unmarshal（从 io.Reader 读时出错）
• ❌ 不属于 IO 错误：fmt.Errorf("xxx")、自定义业务错误、strconv.Atoi 解析失败、JSON 语法错误（json.SyntaxError 是解析逻辑错误，非 IO）
• ⚠️ 注意：io.EOF 是 io 包定义的哨兵值，但语义上代表“正常结束”，不应当作异常处理

避免踩坑的常见写法

以下做法不推荐，容易失效或不可维护：

• ❌ err.Error() == "no such file or directory" —— 字符串依赖操作系统语言和版本，且会被 fmt.Errorf(... %w) 包装后失效
• ❌ err == os.ErrNotExist —— 若错误被包装（如 fmt.Errorf("read config: %w", err)），等式比较会失败
• ✅ 正确姿势：始终优先用 errors.Is 或 errors.As，它们能穿透多层错误包装（%w）

基本上就这些。IO 错误判断的关键不在“是不是来自 os/io 包”，而在于“能不能用标准方式识别其本质原因”。用对 errors.Is 和 errors.As，就能稳住错误分类逻辑，不被包装干扰，也不受语言环境影响。