IOException 是受检异常，因文件读写等操作依赖外部环境、可预见可恢复，故编译器强制处理；throws 用于底层暴露风险，try-catch 用于上层决策恢复策略。
Java 中的 IOException 必须处理，根本原因不是语法强制，而是它被设计为**受检异常（checked exception）**——编译器会强制你面对“这个操作可能失败”这一事实。
为什么 IOException 是受检异常而不是运行时异常
Java 设计者认为：文件读写、网络通信、设备 I/O 等操作天然依赖外部环境（磁盘是否满、网络是否断开、权限是否足够），这些失败是**可预见、可恢复、应主动应对**的，而非程序逻辑错误。因此把 IOException 及其子类归入 Exception 分支（非 RuntimeException），让编译器在编译期就拦截未处理路径。
- 对比
NullPointerException：属于RuntimeException，是代码缺陷，不该靠 try-catch “兜底” -
IOException的典型场景如new FileInputStream("a.txt")、socket.getOutputStream().write(...)，失败概率高且常需重试、降级或提示用户 - 若把它改成非受检异常，大量 I/O 调用将静默失败，生产环境极易出现“没报错但数据没写进去”的诡异问题
throws 和 try-catch 怎么选才不算滥用
二者不是二选一，而是职责分层：底层暴露风险，上层决定策略。
-
工具类方法（如封装 JSON 读取）适合
throws IOException：不假设调用方如何恢复，把决策权交出去 - 业务入口（如 Spring Controller 的
@PostMapping方法）必须try-catch或用全局异常处理器捕获IOException，否则 HTTP 请求直接 500 - 避免在循环里对每次
write()都套独立try-catch——吞掉异常或只打日志会导致部分数据丢失却不报警 - 别写
catch (IOException e) { e.printStackTrace(); }：控制台输出在容器环境几乎不可见，且掩盖了异常类型和上下文
常见误用：用 try-with-resources 就算处理了？
不。自动关闭资源（AutoCloseable）解决的是资源泄漏，不是异常处理本身。以下代码仍通不过编译：
立即学习“Java免费学习笔记（深入）”；
void read() {
try (FileInputStream fis = new FileInputStream("x.txt")) {
fis.read(); // 编译错误：未处理 IOException
}
}
正确写法必须显式声明或捕获：
void read() throws IOException {
try (FileInputStream fis = new FileInputStream("x.txt")) {
fis.read();
}
}
或：
void read() {
try (FileInputStream fis = new FileInputStream("x.txt")) {
fis.read();
} catch (IOException e) {
throw new RuntimeException("读取配置失败", e); // 包装后抛出，不丢失原始栈
}
}
-
try-with-resources的close()也可能抛IOException，若try块已抛异常，关闭异常会被抑制（suppressed），需通过e.getSuppressed()检查 - JDK 7+ 的多异常捕获（
catch (IOException | SQLException e)）不能省略对IOException的处理责任
真正容易被忽略的点是：很多现代 API（如 Files.readString()、Files.write()）仍抛 IOException，哪怕看起来只是操作一个字符串。别因为方法名简单就以为它“不会出错”。
