try-with-resources通过jvm自动保障资源关闭，杜绝泄漏：实现autocloseable的资源声明即受保护，按逆序安全关闭，异常不掩盖主错误，java 9支持外部effectively final变量，职责分离提升健壮性。
用 try-with-resources 提升代码健壮性，核心在于把“资源必须关闭”这件事从人为责任变成 JVM 保障。它不只让代码更短，更关键的是堵住了资源泄漏这个常见生产事故源头。
确保资源一定被关闭，哪怕中途抛异常
传统 try-catch-finally 容易漏掉 finally，或在 finally 里又抛新异常掩盖主错误。try-with-resources 编译后会自动生成安全的关闭逻辑，无论 try 块是正常结束、return 退出，还是抛出任意异常，close() 都会被调用。
- 只要资源类实现 AutoCloseable（比如 FileInputStream、Connection、Scanner），声明即受保护
- 不需要写 finally，也不用判空检查，JVM 自动处理
- 即使 close() 方法本身抛异常，也不会吞掉 try 块里的原始异常——它会被作为 suppressed exception 附加到主异常上，可通过 e.getSuppressed() 查看
多个资源按依赖顺序安全释放
多个资源常存在嵌套依赖（比如 BufferedInputStream 包裹 FileInputStream），关闭时必须先关外层、再关内层，否则可能报错或失效。try-with-resources 默认按声明逆序关闭，天然适配这种依赖关系。
- 写法：try (A a = new A(); B b = new B()) { ... } → 先关 b，再关 a
- 不用手动记顺序，编译器和 JVM 一起帮你守规矩
- 若某资源关闭失败，不影响其他资源继续关闭，且异常不会丢失
Java 9 起支持外部声明变量，逻辑更清晰
以前必须把资源创建写在 try() 里，导致复杂初始化（比如带配置的 HttpClient）被迫挤进一行，可读性差。Java 9 允许直接引用已声明的 effectively final 变量，让资源创建和使用解耦。
- 示例：BufferedReader r = new BufferedReader(...); try (r) { ... }
- 变量 r 在 try 前定义，后续没被重新赋值，就满足 effectively final 条件
- 方便在 catch 或 finally 中访问资源状态，也利于单元测试时替换模拟对象
配合 try-catch 分层设计，错误边界更明确
try-with-resources 管资源生命周期，try-catch 管业务异常流向，两者分工明确。一个块只做一件事，出问题容易定位。
- 资源块内专注数据处理，不混杂关闭逻辑
- catch 块只捕获真正能处理的异常类型（如 IOException），避免 catch(Exception) 掩盖问题
- 可在外层加逻辑块做降级：比如网络请求失败时，用本地缓存兜底，而不是让整个方法崩溃
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
