受检异常与资源关闭本质是同一问题的两面，均要求开发者显式应对确定性风险；其设计意图是将资源生命周期与异常传播路径对齐，通过编译强制确保异常被看见、资源被释放。
Java受检异常（Checked Exception）和外部资源关闭本质上是同一类问题的两个侧面：它们都指向“程序无法自主恢复、但必须由开发者显式应对”的确定性风险。处理好这两者，关键在于理解其设计意图——不是为了增加编码负担，而是把资源生命周期与异常传播路径对齐。
为什么受检异常常出现在资源操作中
像 IOException、SQLException 这类受检异常，几乎总在打开文件、连接数据库、发起HTTP请求等场景下抛出。这是因为这些操作依赖外部环境（磁盘状态、网络连通性、权限配置），JVM 无法保证其必然成功，但又不能忽略失败后果（如文件未关闭导致句柄耗尽）。编译器强制要求处理，就是在提醒：“这里可能出事，你得想好怎么兜底。”
- 不捕获或声明 IOException，代码根本编译不过
- 这种强制不是限制，而是把“资源是否释放”和“异常是否被看见”绑定在同一处逻辑中
- 若用非受检异常替代（比如包装成 RuntimeException），就等于主动放弃编译期防护，容易遗漏清理
资源关闭必须紧贴异常发生点
传统 try-catch-finally 中手动关闭资源，容易出错的根本原因，是关闭逻辑和异常处理逻辑物理分离。比如：
- finally 块里调用 close() 本身可能再抛 IOException，掩盖原始异常
- 多个资源需逐个判空关闭，代码重复且易漏
- 如果 try 块中已 return，finally 仍执行，但关闭时机不可控
而 try-with-resources 把声明、使用、关闭三者统一到一个语法结构里，让资源生命周期完全由 JVM 管理，不再依赖程序员记忆或手写逻辑。
立即学习“Java免费学习笔记（深入）”；
关闭顺序与异常抑制的配合逻辑
当多个资源在同一个 try-with-resources 中声明时，关闭顺序是“后声明先关闭”，这符合资源间的依赖关系。例如：
try (BufferedReader reader = new BufferedReader(...);
FileInputStream fis = new FileInputStream(...)) { ... }
会先关 reader（它内部持有了 fis），再关 fis。更重要的是，如果 fis.close() 抛异常，而 reader.close() 已成功，这个异常不会丢失——它会被作为 suppressed exception 附加到主异常上，通过 getSuppressed() 可查。这样既保证了所有资源都被尝试关闭，又保留了原始错误上下文。
真正要规避的不是异常，而是“状态不一致”
比“如何捕获 IOException”更关键的问题是：“资源关闭失败后，业务状态是否还能继续？”
- 如果只是读一个配置文件失败，可以降级用默认值，此时异常可记录后忽略
- 如果正在事务中写数据库，连接突然断开，就不能简单重试，而要回滚并通知上游
- ClosedChannelException 这类明确表示“通道已终结”的异常，绝不能重试写操作，必须立即清理上下文、重建连接
也就是说，受检异常的处理策略，要根据资源所承载的业务语义来定，而不是统一 try-catch-log。
