java中try-with-resources对多个流关闭异常的处理是保留主异常、压制其余异常，主异常来自try块或首个close()，其余异常通过addsuppressed()附加；关闭逆序执行，压制顺序取决于close调用先后；被压制异常需显式获取，日志中应分级标注，close()宜静默处理预期失败，必要时改用手动管理。
Java 中 try-with-resources 对多个流关闭异常的处理，不是“合并”，而是**保留主异常、压制其余异常**。关键在于理解 JVM 的抑制（suppression）机制，而不是期待多个异常被融合成一个。
主异常始终来自 try 块或第一个 close()
当 try 块内抛出异常（如 NullPointerException），且后续多个资源的 close() 也失败时，try 块的异常成为主异常；所有 close 异常都会被调用 addSuppressed() 方法附加到它身上，不会丢失，但也不会取代它。
如果 try 块正常执行，而多个 close 失败，则第一个被调用的 close() 抛出的异常作为主异常，其余 close 异常被压制。
- 关闭顺序是逆序：声明在后的资源先 close（LIFO）
- 所以压制顺序取决于 close 调用先后——后声明的资源先关，它的异常更可能成为主异常（若 try 块没异常）
被压制的异常必须主动获取才能看到
e.printStackTrace() 在部分环境（如 IntelliJ 控制台、Log4j 默认配置）中默认不显示 suppressed 区块，容易误判问题根源。
正确做法是在 catch 块中显式检查：
- 判断
e.getSuppressed().length > 0 - 遍历
e.getSuppressed()数组，提取每个异常的类名和消息 - 日志中建议：主异常用
error级别，压制异常用warn级别并标注 “Suppressed”
close() 方法应尽量避免抛出干扰性异常
资源的 close() 职责是“尽最大努力清理”，不是严格校验状态。常见终态（如 socket 已断开、流已关闭）引发的异常应静默吞掉。
- 例如
SocketException: socket closed或IOException: Stream closed属于预期失败，可捕获后忽略 - 只对真正危险的情况（如缓冲区 flush 失败且数据可能丢失）才抛
RuntimeException - 参考
Closeables.closeQuietly()的设计思路：吞掉静默失败，不制造额外噪音
必要时放弃 try-with-resources，改用手动管理
当需要控制关闭顺序、单独重试某资源、或 close 行为高度定制时，传统方式反而更可控。
- 每个
close()单独包裹 try-catch，绝不 throw 新异常 - 若需保留原始异常，按标准模式：先保存主异常，close 失败时调用
primary.addSuppressed(e) - 切忌在 finally 中直接写
resource.close()不加 try-catch——这是覆盖原始异常的高发场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
