try-with-resources 底层是编译器将语句重写为带 finally 的显式 close 调用，资源须实现 AutoCloseable 接口，按声明逆序关闭，close 异常作为 suppressed exception 附加到主异常上。
try-with-resources 的底层原理是什么
它不是语法糖，而是编译器强制插入 close() 调用的机制。Java 编译器会把 try-with-resources 语句重写为带显式 finally 块的代码，并在其中调用每个资源的 close() 方法 —— 即使发生异常也会执行。
关键点：资源必须实现 AutoCloseable 接口（Closeable 是其子接口），否则编译不通过。
常见错误现象：Cannot resolve symbol 'resource' 或 resource is not AutoCloseable，往往是因为用了自定义类但没实现接口，或用了老版本 JDK（try-with-resources 从 JDK 7 引入）。
多个资源声明时的关闭顺序怎么确定
资源按声明顺序**逆序**关闭：先声明的后关闭，后声明的先关闭。这很重要，尤其当资源之间存在依赖关系时（比如流包装了另一个流）。
立即学习“Java免费学习笔记（深入）”；
例如：
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedInputStream bis = new BufferedInputStream(fis)) {
// ...
}
bis 先关闭，再 fis 关闭 —— 这样才能保证 bis 不在关闭后还试图操作已关闭的 fis。
- 如果手动写
finally，容易写成正序关闭，导致IOException: Stream closed - 多个资源间有嵌套依赖时，逆序是唯一安全顺序
- 即使某个
close()抛异常，后续资源仍会继续关闭（JDK 7+ 支持 suppressed exception）
为什么 close() 抛异常会导致主异常被掩盖
当 try 块抛出异常，且 close() 也抛异常时，主异常会被保留，close() 异常作为 suppressed exception 附加在其上。但如果你只打印 e.toString() 或没调用 getSuppressed()，就完全看不到关闭失败的线索。
典型表现：程序报 NullPointerException 或 IOException，但实际根源是 close() 失败（如磁盘满、网络中断），而原始业务异常被压住了。
- 调试时务必用
e.printStackTrace()，它会输出 suppressed 异常 - 生产环境日志若只记录
e.getMessage()，大概率漏掉关键上下文 - 自定义
close()实现中，避免在关闭逻辑里 throw 新异常，除非真有必要
哪些常见类不支持 try-with-resources 或需要特别注意
绝大多数标准 I/O 类都支持，但有几个易踩坑的点：
-
Scanner实现了AutoCloseable，但它关闭的是底层Readable（比如System.in）—— 关闭Scanner(System.in)后，后续再读System.in会直接抛IllegalStateException -
Connection/Statement/ResultSet都支持，但 JDBC 4.1+ 才保证所有驱动严格遵循规范；某些老旧驱动的close()可能是空实现或抛SQLException而非RuntimeException -
ZipOutputStream必须显式调用finish()，否则压缩内容可能不完整 ——close()会自动调用finish()，但前提是没提前抛异常中断流程
最常被忽略的是：资源变量必须是 final 或 effectively final，否则编译报错 resource specification is not a valid variable declaration。
