Files.lines() 返回的 Stream 不是 AutoCloseable，必须显式关闭以防文件句柄泄漏；Java 9+ 支持 try-with-resources 直接管理其返回流，但推荐用 Files.newBufferedReader + try-with-resources 确保兼容与安全。
Files.lines() 返回的 Stream
Files.lines() 的真实行为
它内部打开一个通道（通常是 Files.newBufferedReader + Channels.newInputStream），构建一个延迟求值的 Stream。这个 Stream 实现了 BaseStream，但没实现 AutoCloseable。JDK 文档明确指出：必须显式调用 close()，否则缓冲区、文件锁、系统句柄都可能长期占用。
- 调用 .count()、.collect() 等终端操作后，Stream 通常会自动关闭——但这只适用于大多数标准场景，不保证 100% 安全（例如中途异常、短路操作未完成、自定义 Spliterator）
- 若用 forEach 或 peek 处理，Stream 不会自动关闭；流未消费完就退出，资源就彻底泄漏
- IDEA 或 SonarQube 会直接标红警告：“Stream may not be closed”
为什么不能依赖 finally 手动 close()
手动在 finally 块里调用 stream.close() 看似可行，但容易漏掉异常路径或重复关闭。更关键的是：Stream 的 close() 方法本身可能抛出 IOException，而 finally 中未捕获的异常会覆盖 try 块原有的业务异常，导致错误掩盖。
- try 块中发生 NullPointerException，同时 close() 抛出 FileSystemException → 最终只抛出后者，前者丢失
- 如果流已被部分消费或已关闭，再调 close() 可能抛 IllegalStateException
- 没有 try-with-resources 的语法保障，团队协作中极易被忽略
正确写法：用 try-with-resources 包裹可关闭的源头
别把 Files.lines() 直接放进 try() 括号——它不实现 AutoCloseable，编译失败。真正该放进括号的是它的源头，比如 BufferedReader：
try (BufferedReader reader = Files.newBufferedReader(Paths.get("data.txt"))) {
reader.lines().forEach(System.out::println);
}
或者更稳妥地，用 Stream 支持的 try-with-resources 方式（Java 9+）：
Stream<String> lines = Files.lines(Paths.get("data.txt"));
try (lines) { // Java 9 起允许对 effectively final 的 AutoCloseable 变量这样写
lines.forEach(System.out::println);
}
- Java 9+ 中，Stream 接口虽未实现 AutoCloseable，但 Files.lines() 返回的特定 Stream 实现类（如 StreamSupport.stream(...).onClose(...) 构造的）重写了 close() 并委托到底层 Reader ——前提是 JDK 版本 ≥ 9 且未被中间操作中断链
- 仍推荐优先使用 Files.newBufferedReader + try-with-resources，逻辑清晰、版本兼容、关闭确定
自定义封装时的注意事项
如果封装了一个 readLines() 工具方法并返回 Stream，务必让该方法返回类型为 Stream & AutoCloseable（需用类型擦除技巧），或干脆不返回 Stream，改用 Consumer<String> 回调方式，彻底规避关闭责任外移。
- 返回 Stream 时，必须文档注明“调用方负责关闭”，并在 Javadoc @throws 中声明 IOException
- 禁止在工具方法内部 try-with-resources 后直接 return stream —— 那样流还没开始读就关了
- 若坚持返回可关闭 Stream，可用 Stream.of(...).onClose(...) 手动绑定关闭逻辑，但需确保底层资源生命周期可控
