Files.lines() 更适合日志关键字扫描因其返回惰性Stream，配合findFirst()可提前终止，避免全量读取；而BufferedReader需手动break且易漏close。JVM对短路操作深度优化，首次匹配靠前时性能优势显著。
Files.lines() 为什么比 BufferedReader 更适合日志关键字扫描
因为 Files.lines() 返回的是惰性求值的 Stream<string></string>，遇到第一个匹配就可提前终止（配合 findFirst() 或 anyMatch()），而传统 BufferedReader 循环必须手动控制 break，且容易漏掉 close 逻辑。JVM 对 Stream 的短路操作有深度优化，尤其在大文件中“首次 ERROR 出现靠前”时，性能差距明显。
但注意：Files.lines() 底层仍用 BufferedReader，所以缓冲区大小不可调；若需自定义缓冲（如 8KB → 64KB），就得退回到手动 BufferedReader。
filter + findFirst() 是最简高效组合
直接对每行做 String.contains("ERROR") 判断，配合 findFirst() 实现“找到即停”，避免全量加载或遍历。别用 collect(Collectors.toList())，那会强制读完整个文件。
-
filter(line -> line.contains("ERROR"))最轻量，不涉及正则编译开销 - 若需忽略大小写，改用
line.toLowerCase().contains("error")，但注意小写转换会创建新字符串——对超长日志行有 GC 压力 - 若要匹配完整单词（如排除 "ERROR_CODE"），必须用正则
line.matches(".*\bERROR\b.*")，但会显著变慢，慎用 - 务必用
try-with-resources包裹Files.lines()，否则流未关闭会导致文件句柄泄漏
常见错误：空指针、编码乱码、路径不存在
Files.lines() 默认用 UTF-8 解码，而生产日志常为 GBK、ISO-8859-1 或系统默认编码。一旦解码失败，会抛 UncheckedIOException，堆栈里可能只显示 “Malformed input or input contains unmappable characters”，根本看不出是编码问题。
- 显式指定编码：用
Files.lines(path, StandardCharsets.UTF_8)或Charset.forName("GBK") - 行内容为空时
line.contains("ERROR")安全，但若后续有line.split(...)[0]类操作，必须先判空 -
Paths.get("app.log")若路径不存在，Files.lines()抛IOException，不是NullPointerException——别在 catch 里只捕获 NPE - Windows 路径含反斜杠时，用
Paths.get("C:\logs\app.log")或正斜杠"C:/logs/app.log"，别拼字符串
真实示例：带异常防护的极速 ERROR 定位
try (Stream<String> lines = Files.lines(Paths.get("app.log"), StandardCharsets.UTF_8)) {
Optional<String> firstError = lines
.filter(line -> line != null && line.contains("ERROR"))
.findFirst();
if (firstError.isPresent()) {
System.out.println("First ERROR line: " + firstError.get());
} else {
System.out.println("No ERROR found");
}
} catch (IOException e) {
System.err.println("Failed to read log: " + e.getMessage());
}
这里 line != null 是防御性检查——虽然 Files.lines() 文档说不会返回 null，但某些老旧 JDK 补丁版本或自定义 FileSystemProvider 可能破坏契约。多这一行判断，能避开极少数环境下的 NullPointerException。
真正影响“极速”的从来不是函数名，而是你是否跳过了第一行就中断、是否用了正确编码、是否让异常穿透到上层吞掉关键信息。
