Java中try-with-resources必须用AutoCloseable接口，因仅其实现类才能被自动调用close()；自定义类需实现它并妥善处理重复关闭、null检查及异常类型；捕获IOException比Exception更精准，避免掩盖逻辑错误。
Java中try-with-resources为什么必须用AutoCloseable
因为只有实现了AutoCloseable接口的类，才能被try语句自动调用close()方法。像FileInputStream、BufferedReader这些标准IO类都实现了它；但如果你自己写的工具类没实现这个接口，放进try-with-resources里会编译报错：Cannot use this type in a try-with-resources statement。
实操建议：
- 自定义资源类时，务必继承
AutoCloseable并重写close()，且内部要处理好重复关闭和null检查 - 不要在
close()里抛出非IOException的受检异常——否则会被编译器拒绝 - 如果资源初始化失败（比如构造函数抛
IOException），try块还没进入，自然也不会触发close()
捕获IOException还是Exception更合适
直接捕获IOException更精准。Java IO体系里，所有底层读写失败（文件不存在、磁盘满、网络中断等）都归为此类；而笼统抓Exception会掩盖逻辑错误，比如把NullPointerException也吞掉，反而难定位问题。
常见误用场景：
立即学习“Java免费学习笔记（深入）”；
- 用
catch (Exception e)代替catch (IOException e)，结果e.printStackTrace()输出了空指针堆栈却以为是IO问题 - 在Lambda里做IO操作（如
Files.lines().forEach(...)），没意识到IOException无法直接抛出，必须包装成运行时异常或改用传统循环 - Spring等框架中，有些封装方法（如
Resource.getFile()）可能抛FileNotFoundException——它是IOException子类，但单独捕获能更快区分“文件未找到”和“读取失败”
Files.copy()抛出FileSystemException却不是IOException
Files.copy()底层可能触发操作系统级错误（如权限不足、目标路径被占用、跨文件系统硬链接失败），此时抛的是FileSystemException，它继承自IOException，所以用catch (IOException e)能兜住；但它的reason字段和file字段对排障更有价值。
实操建议：
- 别只打印
e.getMessage()，优先用e.getReason()获取OS原生错误描述（如“Permission denied”） - 用
e.getFile()确认出问题的具体路径，尤其在拼接路径时容易忽略Paths.get()的相对路径行为 - 若需区分场景，可二次判断：
if (e instanceof FileSystemException fs) { ... }
BufferedOutputStream.flush()失败要不要重试
不用。一旦flush()抛出IOException，说明缓冲区数据已无法写入目标（比如磁盘已满、网络连接断开），重试只会再次失败。真正该做的是：记录错误上下文（当前写入字节数、目标路径）、清理资源、通知上层失败。
容易被忽略的点：
-
flush()不等于close()：close()内部会自动flush()，所以显式调用后又close()是冗余的，除非你需提前感知写入状态 - 某些场景下（如日志输出流），可用
setAutoFlush(true)避免手动flush()，但会牺牲性能 - 如果写入的是socket流，
flush()失败往往意味着对方已断连，此时再write()会直接抛SocketException
