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，就能稳住错误分类逻辑，不被包装干扰，也不受语言环境影响。
