关键在于声明顺序而非嵌套：资源须按底层到高层顺序声明，jvm逆序调用close()，确保高层先关、底层后关；错误顺序或手动创建未纳入管理的资源会导致关闭异常或资源泄漏。
关键不是“嵌套”而是声明顺序——Java 的 try-with-resources 本身不支持语法上的嵌套声明，所谓“嵌套包装流”，实际是依赖关系的资源链（比如 FileInputStream → BufferedInputStream → ObjectInputStream），必须按**底层到高层**顺序声明，才能保证关闭时**高层先关、底层后关**。
声明顺序必须是：底层流在前，包装流在后
这是唯一能保障正确释放的写法。JVM 按声明逆序调用 close()，所以要把依赖别人、又需要别人活着才能正常关闭的流，放在后面声明。
- ✅ 正确示例：
try (FileInputStream fis = new FileInputStream("a.txt");<br> BufferedInputStream bis = new BufferedInputStream(fis);<br> ObjectInputStream ois = new ObjectInputStream(bis)) {<br> // 使用 ois<br>}
→ 关闭顺序：ois.close() → bis.close() → fis.close()，缓冲刷新、反序列化清理都来得及。 - ❌ 错误示例：
try (ObjectInputStream ois = new ObjectInputStream(...);<br> FileInputStream fis = new FileInputStream("a.txt")) { ... }
→ ois 先关，内部可能已把 fis 关掉或置为无效；fis 再关就会抛Stream closed异常。
别用外层 try 包内层 try 模拟“嵌套”
这种写法看似结构清晰，实则破坏了统一关闭机制：
- 内层流（如
BufferedInputStream）在内层try结束时立刻关闭； - 外层流（如
FileInputStream）要等到外层try结束才关； - 两者生命周期被割裂，异常抑制失效，
close()失败容易被掩盖，调试困难； - 还可能因重复关闭或提前关闭引发运行时异常。
所有资源必须实现 AutoCloseable，且不能提前创建再赋值
除非用 Java 9+ 的“有效 final 变量复用”特性，否则资源必须在 try 括号里直接 new 出来：
- ✅ 支持：
try (var fis = new FileInputStream("a.txt");<br> var bis = new BufferedInputStream(fis)) { ... }（Java 10+ var + Java 9+ 外部变量复用） - ⚠️ 不推荐（易出错）：
FileInputStream fis = new FileInputStream("a.txt");<br>try (BufferedInputStream bis = new BufferedInputStream(fis)) { ... }
→ fis 没被纳入自动管理，仍需手动关或靠 finally，违背 try-with-resources 初衷。 - ❌ 编译失败：
Scanner sc = new Scanner(System.in);<br>try (sc) { ... }（Java 18 及更早版本，Scanner 未实现 AutoCloseable）
异常处理：主异常优先，关闭异常会被抑制
如果 try 块抛出异常，而某个 close() 也失败，后者不会覆盖前者，而是被添加为 suppressed exception：
- 可通过
e.getSuppressed()获取所有被压制的异常； - 尤其要注意：包装流的
close()可能触发底层流的异常（如网络断开、磁盘满），这些信息藏在 suppressed 里，不查就容易漏掉根因。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
