try-with-resources中close()异常会被抑制而非覆盖主异常；主异常始终抛出，close异常可通过getSuppressed()获取；应主动检查处理被抑制异常，优化close实现以减少异常，并在必要时改用手动finally管理。
在自动关闭资源（如 try-with-resources）中，如果
方法抛出异常，Java 会按规则抑制（suppressed）它，而不是覆盖主异常——前提是已有另一个异常正在传播。关键不是“避免 close 抛异常”，而是理解并正确应对它的存在。
理解 try-with-resources 的异常处理机制
当 try 块正常结束、没有异常时，
抛出的异常会直接向上抛出；当 try 块已抛出异常（比如 IOException），而
又抛出另一个异常，后者会被作为“被抑制异常”附加到主异常上，可通过
获取。
主异常（try 块中抛出的）始终是最终抛出的那个
close 异常不会丢失，只是默认不显示在堆栈跟踪首行
所有被抑制异常仍可被程序主动检查和处理
显式检查并处理被抑制的异常
不要依赖日志或 IDE 默认输出——它们常忽略 suppressed 异常。应在捕获主异常后，主动遍历并记录或决策：
用
获取数组，逐个判断类型或消息
对关键资源（如数据库连接池释放失败），即使 close 报错也应打 warn 日志，避免掩盖泄漏迹象
若多个资源 close 都失败，可聚合信息统一上报，而非只处理第一个
让 close 方法更健壮，减少意外抛异常
的设计目标是“尽最大努力清理”，不应因内部状态异常（如流已关闭、网络已断开）就抛出检查型异常。建议：
在 close 实现中捕获并吞掉底层已关闭/无效状态导致的异常（如 SocketException: socket closed）
仅对真正不可恢复的错误（如写缓冲区 flush 失败且数据可能丢失）才抛 RuntimeException
使用 Apache Commons IO 或 Guava 的
类似逻辑作参考
需要完全控制 close 行为时，放弃 try-with-resources
某些场景下（如必须确保 close 按特定顺序执行、或需对每个 close 单独重试），手动管理更清晰：
用传统 try-finally，把 close 放在 finally 块中，并各自 try-catch
对每个资源独立处理 close 异常，不依赖抑制机制
适合集成老框架、或 close 逻辑含业务语义（如 close 同时触发回调）的情况
close()close()close()getSuppressed()exception.getSuppressed()close()Closeables.closeQuietly()