files.lines()适合读超大文件因其返回惰性stream，底层基于bufferedreader按需加载行，不全量缓存，内存仅取决于单行长度和缓冲区大小，避免oom；但必须用try-with-resources显式关闭，否则导致文件句柄泄漏。
Files.lines() 为什么适合读超大文件
它返回的是 Stream<string></string>，底层基于 BufferedReader，按需加载行、不缓存全文，内存占用基本只取决于单行长度和缓冲区大小（默认 8192 字节）。相比 Files.readAllLines() 一次性把全部行塞进 List，它不会触发 OOM。
但注意：这个 Stream 是**有资源绑定的**——背后持有一个未关闭的文件通道。如果不用 try-with-resources 包裹或手动 close，会导致文件句柄泄漏，尤其在循环处理多个文件时容易踩坑。
必须用 try-with-resources 包裹 Stream
Files.lines() 返回的流实现了 AutoCloseable，但很多人忽略这点，直接链式调用后丢弃引用：
Files.lines(Paths.get("huge.log"))
.filter(line -> line.contains("ERROR"))
.findFirst(); // ❌ 流没关闭，文件句柄泄漏
正确写法是显式声明并用 try-with-resources 管理：
try (Stream<string> lines = Files.lines(Paths.get("huge.log"))) {
lines.filter(line -> line.startsWith("[WARN]"))
.limit(10)
.forEach(System.out::println);
} catch (IOException e) {
// 处理 IO 异常
}</string>
常见错误现象：java.io.IOException: Too many open files —— 就是没关流积累太多句柄导致的。
filter/map/limit 等中间操作不会立即读文件
Stream 的惰性求值特性在这里是优势：你加再多 filter、map、skip，只要没触发终止操作（如 count()、collect()、forEach()），文件根本不会被打开。
这意味着你可以安全地构建处理逻辑，比如：
-
lines.skip(1000000)跳过前百万行再处理，不会提前加载它们 -
lines.limit(100)只读前 100 行，哪怕文件有 10GB - 配合
peek()做调试日志，也不会影响性能（只要不滥用）
但注意：sorted() 或 collect(Collectors.toList()) 这类操作会强制消费全部流，失去内存优势，等价于全量加载。
编码问题必须显式指定，不能依赖平台默认
Files.lines(path) 默认用 StandardCharsets.UTF_8，但如果文件是 GBK、ISO-8859-1 或其他编码，会乱码甚至抛 MalformedInputException。
务必用带 Charset 参数的重载：
try (Stream<string> lines = Files.lines(Paths.get("access.log"), StandardCharsets.ISO_8859_1)) {
lines.filter(line -> !line.trim().isEmpty())
.forEach(System.out::println);
}</string>
Windows 上记事本保存的 ANSI 文件大概率是 GBK（非标准），Linux 日志常用 UTF-8，生产环境不指定编码等于埋雷。
真正麻烦的不是读得慢，而是读错字节后整行解析失败、正则匹配失效、数值转换异常——这些错误往往静默发生，直到下游数据对不上才暴露。
