多流拼接时需在try()中按依赖逆序显式声明每层流，确保底层流后声明、后关闭；应主动flush以暴露写入异常；需检查getsuppressed()获取被抑制异常。
多流拼接（比如用 BufferedInputStream 包裹 FileInputStream，或 ObjectOutputStream 包裹 FileOutputStream）时，用 try-with-resources 安全关闭的关键不是“能不能关”，而是“按什么顺序关、会不会漏关、异常怎么处理”。只要写法正确，JVM 会自动关，但顺序错或声明不当，就可能出问题。
必须在 try 括号里分别声明每一层流
不能只声明最外层流，也不能把底层流提前声明在 try 外。否则底层资源不会被自动管理：
- ✅ 正确：每层都显式声明在 try() 中，用分号分隔
- ❌ 错误：
FileInputStream fis = new FileInputStream(...); try (BufferedInputStream bis = new BufferedInputStream(fis)) { ... }→ fis 不在括号里，不会自动关 - ❌ 错误：
try (BufferedInputStream bis = new BufferedInputStream(new FileInputStream(...))) { ... }→ 底层流是匿名对象，无法独立调用 close()，一旦 bis.close() 抛异常，fis 可能没机会关
按依赖关系逆序声明，确保先关包装、后关底层
流的关闭顺序必须匹配其依赖逻辑：上层流操作依赖下层流，所以下层流要“活得更久”——即后声明、后关闭：
- 比如
BufferedInputStream依赖FileInputStream，应先声明 fis，再声明 bis - JVM 关闭时按声明逆序执行：bis 先关 → fis 后关，避免 bis 在 close() 里还尝试读已关闭的 fis
- 同理，
ObjectOutputStream → FileOutputStream → FileOutputStream的链路，也应从外到内声明
显式 flush() 再让 close() 专注释放句柄
带缓冲的流（如 BufferedOutputStream、ObjectOutputStream）的 close() 会隐式调用 flush()，但若 flush 失败（如磁盘满），异常可能被 suppress 掩盖。主动 flush 能提前暴露问题：
- 在 try 块末尾加
out.flush()，让写入失败在主流程中抛出 - 这样
close()就只负责释放文件句柄，行为更轻量、更可预期 - 尤其对日志、配置保存等关键场景，不建议把数据落盘成败全押在 close() 上
检查并处理被抑制的异常
多流关闭时，某一层 close() 抛异常（比如网络流断连、文件系统只读），会被 suppress 并附在主异常上。不查就等于忽略真实失败原因：
- catch 到异常后，用
e.getSuppressed()遍历所有被抑制的异常 - 常见组合如
FileOutputStream + ObjectOutputStream，若 close() 时磁盘满，OS 异常可能被 suppress，而主异常只是 NullPointerException 或其他业务异常 - 开发阶段可在 close() 方法里加日志，确认每层是否真被调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
