BufferedReader.lines() 返回的 Stream 不是无限流，而是延迟加载、一次性消费的流；调用后按需读行，流遍历完或 BufferedReader 关闭后再次使用会抛 IllegalStateException。
BufferedReader.lines() 返回的 Stream 是不是无限流？
不是无限流，但它是延迟加载、一次性消费的流。调用 lines() 后不会立即读取全部内容，而是按需从底层 Reader 拉取行；一旦流被遍历完毕或中途关闭底层 BufferedReader，后续再尝试使用该流会抛出 IllegalStateException。
常见错误现象：Stream has already been operated upon or closed —— 多次调用 count()、collect() 等终端操作，或在流处理中途 close 了 BufferedReader。
- 必须确保
BufferedReader在整个流消费完成前保持打开状态 - 不要对同一个
lines()流重复调用终端操作（比如先count()再forEach()） - 若需多次遍历，应把结果收集到
List或重新创建流（如用Files.lines(path)）
为什么不能直接 try-with-resources 包裹 BufferedReader + lines().forEach()？
因为 try-with-resources 会在语句块结束时自动调用 close()，而 lines() 返回的流是懒加载的 —— 如果你在 forEach() 中做耗时操作（比如网络请求、数据库写入），或者用了 skip()/limit() 等中间操作，close() 可能提前触发，导致后续读取抛出 IOException。
正确做法是让流的生命周期和资源关闭对齐：
- 用
try-with-resources+ 终端操作（如collect(Collectors.toList())）—— 流会完整消费并触发关闭 - 手动管理：先获取
Stream<string></string>，处理完再显式br.close() - 更推荐用
Files.lines(Paths.get("xxx.txt"))，它返回的流自带资源管理（关闭流即关闭文件）
lines() 和 Files.lines() 在路径编码和异常处理上有啥区别？
BufferedReader.lines() 本身不涉及路径，只依赖已构建好的 Reader；而 Files.lines() 直接接受 Path，默认使用 UTF-8 解码，且声明抛出 IOException —— 这意味着你必须处理异常，不能像 BufferedReader 那样隐藏在 try-catch 里。
-
Files.lines(path)默认 UTF-8，若文件是 GBK，得用Files.lines(path, Charset.forName("GBK")) -
BufferedReader构造时可传入指定Charset，其lines()就继承该编码 -
Files.lines()的流在终端操作后自动关闭底层通道；BufferedReader.lines()不会自动关，必须你自己关
示例对比：
Files.lines(Paths.get("data.txt"))
.filter(line -> line.startsWith("#"))
.count(); // ✅ 自动释放资源
BufferedReader br = Files.newBufferedReader(Paths.get("data.txt"));
br.lines()
.filter(line -> line.startsWith("#"))
.count();
br.close(); // ❌ 必须显式 close，漏掉就泄露资源
Stream 处理大文件时内存会不会爆？
不会，lines() 是典型的惰性流：每次只读一行进内存，filter/map 等中间操作也不缓存整条数据，只有终端操作（如 collect()）才可能累积结果。但要注意几个隐性坑：
- 如果用
collect(Collectors.toList())加载百万行，那确实会 OOM —— 改用forEach()或分批处理（limit(1000).forEach()） - lambda 中持有外部大对象引用（比如把整个
br或上下文塞进闭包），会导致无法 GC - 正则匹配（
line.matches(".*?")）或字符串重复分割（line.split(",").length）在长文本下 CPU/内存开销陡增
真正影响性能的往往不是 lines() 本身，而是你后续怎么用它。
