java中try-with-resources多资源声明须用分号分隔、在try括号内独立声明；初始化从左到右，关闭严格逆序（后声明先关闭），确保依赖资源安全释放，如bufferedoutputstream在fileoutputstream后声明则先关闭。
try-with-resources 中多个资源的声明语法和执行顺序
多个资源必须用分号分隔，且声明位置严格在 try 括号内；它们不是按书写顺序初始化，而是从左到右依次执行构造（或表达式求值），但关闭时严格逆序——即最右边声明的资源最先关闭。
常见错误是误以为“先声明先关闭”，结果在资源存在依赖关系时（比如 BufferedWriter 包裹 FileOutputStream）手动调用 close() 导致外层流关闭后内层流再关抛 IOException。而 try-with-resources 自动处理了这种嵌套依赖的关闭时序。
-
try (InputStream is = new FileInputStream("a.txt"); OutputStream os = new FileOutputStream("b.txt")) { ... }：os先于is关闭 - 若某资源构造失败（如
new FileInputStream("missing.txt")抛FileNotFoundException），已成功构造的前面资源会自动关闭（按逆序，即刚构造完的立刻关） - 所有资源类型必须实现
AutoCloseable；JDK 7+ 的Closeable是其子接口，完全兼容
为什么关闭顺序必须是逆序？看字节码和编译器生成逻辑
javac 并不会真的“记住声明顺序然后倒着关”。它把每个资源编译为一个隐式嵌套的 try-finally 块，等价于手写：
try (A a = new A(); B b = new B()) { ... }
// ≡ 编译后近似：
A a = null;
B b = null;
try {
a = new A();
try {
b = new B();
// ... body
} finally {
if (b != null) b.close(); // 先关 b
}
} finally {
if (a != null) a.close(); // 再关 a
}
这种嵌套结构天然保证：越晚构造的资源，其 close() 越早执行。这也是为什么依赖流（如 BufferedWriter 依赖 Writer）能安全关闭——外层流的 close() 通常会触发内层流的关闭，而逆序恰好避免重复关或关已关对象。
- 如果强行改成正序关闭，会导致
BufferedWriter.close()在底层FileWriter已关闭后再次调用其close()，多数实现会静默忽略，但部分自定义AutoCloseable可能抛IllegalStateException - 逆序不是 JVM 层机制，而是 javac 的语义约定；运行时只看到普通 try-finally，无额外开销
捕获多个 close() 异常：suppressed exception 的实际影响
当 try 块正常执行，但多个资源的 close() 都抛异常时，只有第一个（即最晚声明、最先关闭的那个资源）的异常被抛出，其余会作为 suppressed exception 附加到主异常上。
这容易被忽略：用 e.printStackTrace() 看不到 suppressed 异常，必须显式调用 e.getSuppressed() 才能获取。
- 若 try 块本身已抛异常（如
NullPointerException），而某个close()也抛异常（如IOException），则后者会被 suppress，前者为主异常 - suppressed 异常不会中断关闭流程——编译器生成的 finally 块会继续尝试关后续资源，哪怕前一个
close()失败 - 日志框架（如 SLF4J）默认不打印 suppressed 异常，需用
org.slf4j.helpers.SubstituteLogger#log或升级到支持 suppressed 的版本
非标准资源或需要定制关闭行为怎么办？
只要类型实现 AutoCloseable，就可直接用于 try-with-resources。不需要继承特定类或加注解。
但如果想控制关闭逻辑（比如跳过某次 close、合并关闭、或延迟关闭），不能靠改 try-with-resources 语法——它只负责调用 close()。正确做法是包装一层：
- 写个新类
DeferredCloser implements AutoCloseable，把真正要关的资源存为字段，close()中做判断逻辑 - 用 lambda 包装：
try (AutoCloseable c = () -> { if (shouldClose) realResource.close(); }) { ... }（需 Java 8+，注意函数式接口适配） - 不要在
close()里吞异常；即使业务上想忽略 IO 异常，也建议至少打 warn 日志，否则 suppressed 机制会让问题彻底消失
逆序关闭是确定性行为，但它的价值只在资源间有依赖或状态耦合时才凸显；两个独立的 Connection 和 Statement，逆序关只是规范，不是强制需求。真正容易出错的是手动管理关闭顺序和异常聚合的地方。
