try-with-resources 不提供静默关闭，仅保证调用 close()；close() 是否抛异常取决于资源实现，如 bufferedoutputstream.close() 隐式 flush() 可能抛 ioexception，异常不会被吞掉而是作为 suppressed 或主异常出现。
try-with-resources 本身不提供“静默关闭”能力，它只是保证 close() 被调用；所谓“静默”，必须由资源自身或包装逻辑决定是否抛异常。
为什么 close() 有时会抛异常，而你没看到
Java 标准 IO 类（如 FileInputStream、BufferedOutputStream）的 close() 方法声明了 throws IOException，但多数情况下——尤其是读写已结束、底层文件句柄正常释放时——实际执行并不会抛异常。真正容易出问题的是：
-
BufferedOutputStream.close()会隐式调用flush()，若磁盘满或目标不可写，flush()失败 →close()抛IOException -
ZipOutputStream.close()在写完目录头时出错，也会抛异常 - 自定义实现
AutoCloseable时，close()方法里写了throw new RuntimeException("oops")
这些异常不会被“静默吞掉”，而是作为主异常的 suppressed exception 存在，或直接中断流程——除非你显式忽略。
想让关闭不打断流程，得从资源类型和调用方式入手
没有通用的“静默开关”，但可通过以下组合达成效果：
- 用
java.nio.file.Files工具类替代原始流：例如Files.copy(…)内部已处理异常，失败直接抛出，不依赖你关流 - 对必须用
try-with-resources的场景，选已做静默处理的封装类：比如 Apache Commons IO 的Closeable子类（注意：IOUtils.closeQuietly()是手动辅助方法，不能用于 try-with-resources 括号内） - 自己包装一层：写个
QuietCloseable包装流，在close()里 catchIOException并吞掉（仅限明确接受丢失 flush 风险的场景） - 避免在
close()前还有未 flush 的数据：在 try 块末尾加os.flush()，把潜在 IO 错误提前暴露并捕获，让close()变成“纯释放句柄”，更接近静默
try-with-resources 里写 IOUtils.closeQuietly() 是错的
这是常见误解。以下写法是非法且无意义的：
try (InputStream is = new FileInputStream("a.txt")) {
// ...
IOUtils.closeQuietly(is); // ❌ 错误：is 已被声明为 final，且 closeQuietly() 不是 AutoCloseable 实现
} catch (IOException e) { ... }
原因很直接：
-
IOUtils.closeQuietly()是静态工具方法，不返回新资源，也不能放进 try 括号 - 放进括号的必须是实现了
AutoCloseable的实例，而closeQuietly()只是帮你调一次close()并吞异常 - 如果真这么写了，编译器会报错：
not a valid type for auto-closeable resource
正确做法是：要么不用 try-with-resources，改用手动 try-catch-finally + IOUtils.closeQuietly()；要么坚持用 try-with-resources，但接受其原生行为——即关闭失败时异常仍会浮现，只是位置可能在 suppressed 中。
最容易被忽略的点：flush() 不是 close() 的子集，但它常藏在背后
很多开发者以为“关流=数据落盘”，其实不是。例如：
-
BufferedOutputStream的close()会flush()，但FileOutputStream的close()不会刷内核缓冲区（那是 OS 层的事） - 如果你在
try块里没显式flush()，又没触发close()的异常，就可能误以为数据写成功了，实际还卡在用户态缓冲区 - 压制异常（suppressed exception）只在 try 块已有异常时才出现；如果 try 块一切正常，
close()单独抛异常，它就是主异常——这点调试时极易看漏
