IOException 是受检异常，必须 try-catch 或 throws，因其代表外部环境引发的不可预判错误；推荐用 try-with-resources 确保资源关闭，并捕获具体子类而非泛化 Exception。
Java 中的 IO 异常必须显式处理，IOException 是受检异常（checked exception），不捕获或声明就会编译失败——这是和 RuntimeException 最本质的区别。
为什么 IOException 必须 try-catch 或 throws？
因为 Java 设计上将可能由外部环境引发、程序无法提前预判的错误（如磁盘满、网络中断、文件被占用）归为受检异常。JVM 要求你直面这些现实风险，而不是让它们静默崩溃。
-
FileInputStream构造时文件不存在 → 抛FileNotFoundException（IOException子类） -
BufferedReader.readLine()读到流末尾返回null，但若底层连接突然断开 → 抛IOException - 即使
close()也有可能失败（比如写缓冲区刷盘时磁盘满），所以它也声明抛出IOException
try-with-resources 是最安全的写法
手动 close() 容易遗漏或被异常吞掉；用 try-with-resources 可确保资源无论是否异常都会关闭，且自动抑制（suppressed）后续 close 异常。
try (FileInputStream fis = new FileInputStream("data.txt");
BufferedInputStream bis = new BufferedInputStream(fis)) {
int b;
while ((b = bis.read()) != -1) {
// 处理字节
}
} catch (IOException e) {
// 所有 IO 异常在此统一处理
System.err.println("IO error: " + e.getMessage());
}
- 括号内声明的变量必须实现
AutoCloseable接口（InputStream、OutputStream、Reader、Writer等都满足） - 多个资源用分号分隔，关闭顺序与声明顺序相反（后声明的先关闭）
- 如果
try块和close()都抛异常，后者会被添加为 suppressed exception，可通过e.getSuppressed()查看
不要用 catch (Exception e) 吞掉 IO 异常
泛捕获会掩盖真实问题，比如把 FileNotFoundException 和 SecurityException 当成一回事，导致排查困难。
立即学习“Java免费学习笔记（深入）”；
- 优先捕获具体子类：
catch (FileNotFoundException e)、catch (SocketTimeoutException e) - 对无法细分的通用 IO 场景，至少保留
catch (IOException e)，不要向上扩大到Exception - 记录日志时别只打
e.toString()，用e.printStackTrace()或日志框架的logger.error("read failed", e)保留堆栈
自定义 IO 工具方法时，别随意改成运行时异常
有人为了省事把 throws IOException 改成包装成 RuntimeException（如 throw new RuntimeException(e)），这会破坏调用方的异常契约。
- 下游代码原本靠
throws IOException明确知道“这里可能 IO 失败”，改了之后编译器不再提醒，容易漏处理 - 除非你明确设计为“基础设施层兜底”（如 Spring 的
Resource抽象），否则应保持受检异常的传播性 - 若真要简化，可用
UncheckedIOException（Java 8+），它是RuntimeException子类但封装了IOException，语义更清晰
真正难的不是语法，而是判断哪些 IO 异常该重试（如网络超时）、哪些该告警（如配置文件缺失）、哪些该静默跳过（如临时缓存读取失败）——这些逻辑藏在业务里，不在 try 块的花括号中。
