Closeable.close() 抛出 IOException 是明确语义契约，因关闭可能触发真实 I/O 故障；必须显式处理受检异常，合理利用 try-with-resources 抑制机制，close 实现需幂等健壮，关键资源失败须分级响应。

Closeable.close() 抛出 IOException，不是设计缺陷，而是明确的语义契约：关闭过程本身可能触发 I/O 操作（如刷新缓冲、发送 FIN 包、等待磁盘落盘），这些操作天然依赖外部环境，失败即代表真实故障。处理这类变量，核心不是“避免异常”，而是理解其发生场景、控制传播路径、保障资源终态。

close 异常必须声明捕获或声明抛出

因为 IOException 是受检异常（checked exception），任何直接调用 close() 的代码都必须处理它：

• 在 try-with-resources 中，JVM 自动调用 close()，但若该 close() 抛出 IOException，且 try 块未发生异常，则此 IOException 会直接向上抛出
• 在手动调用 close() 时（如 finally 块），必须用 try-catch 包裹，或在方法签名中 throws IOException
• 不能忽略或仅打印日志后吞掉——这会掩盖资源释放失败的真实风险（例如文件句柄未真正关闭）

try-with-resources 中的异常抑制机制要主动检查

当 try 块已抛出一个异常（如读取时的 IOException），而 close() 又抛出另一个 IOException，后者不会覆盖前者，而是作为“被抑制异常”附加到主异常上：

• 主异常始终是 try 块中第一个抛出的异常
• 被抑制异常可通过 exception.getSuppressed() 获取数组，需显式遍历处理
• 日志框架默认不打印 suppressed 异常，必须手动记录，例如：log.warn("资源关闭失败，主异常：{}，被抑制异常：{}", e, Arrays.toString(e.getSuppressed()))

close 实现应尽最大努力，而非轻易抛异常

Closeable 接口要求 close() 具备幂等性与健壮性。合格的 close 实现应：

• 内部用 volatile boolean 标记是否已关闭，重复调用直接返回
• 对已断开连接、已关闭流等“预期中的无效状态”，捕获底层异常（如 SocketException: socket closed）并静默处理
• 仅在真正影响数据完整性或系统状态时才抛 IOException（如 flush 缓冲区失败且数据尚未落盘）
• 避免因锁争用、线程中断等非 I/O 原因抛出 RuntimeException 干扰契约

关键资源关闭失败需业务级响应

不是所有 close 失败都同等重要。应按资源类型分级处理：

• 数据库 Connection 关闭失败 → 触发连接池健康检查，标记为可疑连接，避免复用
• 临时文件流关闭失败 → 记录 warn 日志，尝试 File.deleteOnExit() 作为兜底
• 网络 Socket 关闭失败 → 若已收到对端 FIN，可忽略；若处于半开状态，需记录并告警
• 多个资源嵌套关闭时（如 BufferedInputStream 包裹 FileInputStream），外层 close 失败通常意味着内层也失效，应聚合上报而非逐个重试