IOException是检查型异常，强制处理，反映外部环境问题如磁盘满、文件占用等；应优先用try-with-resources自动关流，可区分子类处理，包装为RuntimeException需谨慎并保留cause。
为什么IOException总在读写文件时突然冒出来？
因为IOException是检查型异常（checked exception），只要调用的API声明抛出它，编译器就强制你处理——哪怕只是临时用try-catch包一下。它不反映代码逻辑错误，而是外部环境出了问题：磁盘满了、文件被占用、网络断开、权限不足、路径不存在……这些都不是你能靠改逻辑避免的。
常见触发点包括：FileInputStream构造、BufferedReader.readLine()、ObjectOutputStream.writeObject()、Files.copy()等I/O操作。一旦发生，程序不会自动终止，但如果不捕获，编译直接失败。
用try-with-resources比try-catch-finally更可靠
老式写法容易漏关流，导致句柄泄漏；try-with-resources在语句块结束时自动调用close()，哪怕发生异常也保证执行。前提是资源类型实现AutoCloseable接口（FileInputStream、BufferedWriter等都满足）。
- 别再手动写
finally { if (in != null) in.close(); } - 多个资源用分号隔开：
try (FileInputStream in = new FileInputStream("a.txt"); BufferedReader r = new BufferedReader(new InputStreamReader(in))) { ... } - 如果
close()本身也抛IOException，它会被抑制（suppressed），可通过Throwable.getSuppressed()获取，主异常仍正常抛出
try (FileInputStream fis = new FileInputStream("data.bin");
DataInputStream dis = new DataInputStream(fis)) {
int value = dis.readInt();
System.out.println(value);
} catch (IOException e) {
// 这里捕获的是readInt()或构造时的IO异常，fis/dis已自动关闭
System.err.println("读取失败: " + e.getMessage());
}
IOException子类值得区分处理吗？
绝大多数场景下不用细分——比如FileNotFoundException和SocketTimeoutException虽然都是IOException子类，但业务恢复策略可能完全不同。真要区分，优先捕获具体子类，再兜底IOException：
立即学习“Java免费学习笔记（深入）”；
-
FileNotFoundException：说明路径无效，可提示用户检查文件是否存在，或自动创建默认配置 -
SocketTimeoutException（继承自IOException）：网络请求超时，适合重试而非报错退出 -
EOFException：常出现在序列化读取中，表示流意外结束，通常意味着数据损坏，应记录并拒绝加载 - 其他未明确子类的情况，统一按“不可恢复的I/O故障”处理，比如记录日志、通知运维、降级到缓存或默认值
try {
loadConfigFromFile();
} catch (FileNotFoundException e) {
System.err.println("配置文件丢失，使用内置默认值");
useDefaultConfig();
} catch (SocketTimeoutException e) {
System.err.println("远程配置加载超时，尝试重试...");
retryLoad();
} catch (IOException e) {
System.err.println("未知I/O错误：" + e.getMessage());
fallbackToSafeMode();
}
抛出IOException时，要不要包装成运行时异常？
可以，但得看上下文。如果你写的工具方法被大量上层代码调用，而每个调用方都不想写try-catch，用RuntimeException包装能简化调用方代码。但代价是：异常类型信息丢失，且违反了Java对I/O失败应显式处理的设计意图。
更稳妥的做法是定义自己的检查型异常，比如StorageException extends IOException，并在方法签名中继续抛出——既保留检查特性，又把底层细节（如NIO还是传统IO）封装掉。
- 不要用
new RuntimeException(e)裸包，至少保留原异常作为cause：throw new RuntimeException("保存用户数据失败", e) - Spring等框架内部常用
org.springframework.dao.DataAccessResourceFailureException这类运行时异常替代IOException，前提是整个项目已约定放弃检查型异常治理 - 命令行工具或脚本类应用可直接包装为
RuntimeException，避免层层throws
真正难处理的不是怎么抛，而是当IOException发生在异步线程、CompletableFuture、或Servlet Filter中时，原始堆栈和上下文极易丢失——这时候必须主动记录线程名、关键参数、时间戳，否则排查起来就是大海捞针。
