主异常优先抛出，其余close异常被抑制并存入getsuppressed()数组；需显式检查 suppressed 异常，按资源类型分类处理、打日志或聚合告警；对无害关闭失败应静默处理，关键场景才抛异常；关闭逻辑复杂时应回退传统 try-finally。
当 try 块和多个资源的 close() 方法都抛出异常时，Java 不会丢弃任何一个——主异常（try 块中首个抛出的）始终被抛出，其余 close() 异常会被“抑制”（suppressed），并附加到主异常对象上。关键不是避免它们出现，而是知道怎么取、怎么看、怎么用。
主异常永远优先，被抑制异常不会消失
只要 try 块内已抛出异常（比如 IOException），后续任意资源的 close() 再抛异常（如第二个流关闭失败），该异常就不会覆盖主异常，而是调用主异常的 addSuppressed() 方法存进去。这意味着：
- 堆栈跟踪默认只显示主异常，IDE 或日志可能不自动打印 suppressed 部分
-
exception.getSuppressed()返回Throwable[]，长度可能为 0、1 或更多（取决于几个资源 close 失败） - 所有被抑制异常仍保留在内存中，可被程序主动检查、分类或上报
必须显式检查 getSuppressed()，不能靠默认输出
很多线上问题排查失败，是因为只看了首行异常，忽略了被压制的线索。例如数据库连接池释放失败、文件句柄未真正关闭等，往往藏在 suppressed 里。建议在 catch 块中统一处理：
- 遍历
e.getSuppressed()，对每个异常做类型判断（如是否是SQLException或IOException） - 对关键资源（如连接、锁、大文件流），即使 close 报错也要打
warn日志，附带资源标识（如 URL、文件名） - 若多个 suppressed 异常同时发生，可聚合信息生成一条结构化告警，而不是只处理第一个
让 close 方法本身更“安静”，减少干扰
不是所有 close 失败都值得上升为异常。设计上应遵循“尽最大努力清理”原则：
- 捕获并静默处理已关闭/无效状态导致的异常（如
SocketException: socket closed、IllegalStateException: stream is closed） - 仅对真实数据风险场景（如 flush 缓冲区失败且可能丢失写入内容）才抛
RuntimeException - 参考
IOUtils.closeQuietly()或Closeables.closeQuietly()的实现逻辑
需要精细控制时，就别用 try-with-resources
当关闭顺序敏感、需单独重试某资源、或 close 含业务语义（如触发回调、更新状态），自动机制反而受限。此时应退回传统方式：
- 用
try-finally，每个资源的close()单独包裹try-catch - 按需决定是否吞掉异常、记录、重试或传播
- 能完全掌控关闭时机与异常流向，不依赖 JVM 的抑制逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
