files.lines()流式读取大文件更简洁且默认utf-8，但须try-with-resources防句柄泄漏；需处理编码探测、nul截断、大小写匹配、滑动窗口上下文、正则预编译、行号控制及高亮安全替换。
用 Files.lines() 流式读取并搜索关键词
直接逐行扫描大文件时，Files.lines() 比传统 BufferedReader 更简洁且默认 UTF-8 编码，适合大多数文本场景。但要注意它返回的是 Stream<string></string>，必须用 try-with-resources 包裹，否则流未关闭会导致文件句柄泄漏。
- 搜索匹配行需调用
filter(line -> line.contains("keyword"))，注意contains()区分大小写 - 若需忽略大小写，改用
line.toLowerCase().contains(keyword.toLowerCase())，但对超长行有性能开销 - 遇到含 NUL 字符（
\u0000）的二进制伪装文本文件时，Files.lines()会提前截断——此时必须退回到BufferedReader
处理编码未知或非 UTF-8 的文件
用户拖进来的日志可能用 GBK、ISO-8859-1 甚至带 BOM 的 UTF-8，硬写死 StandardCharsets.UTF_8 会导致乱码漏匹配。Java 没有内置自动编码探测，得靠第三方库或简单启发式判断。
- 优先检查文件头 BOM：
EF BB BF→ UTF-8，FF FE→ UTF-16LE，FE FF→ UTF-16BE - 若无 BOM，可尝试用
juniversalchardet库做轻量探测（注意其对短文本准确率低） - 实际项目中更稳妥的做法是暴露编码参数：命令行加
--encoding=GBK，GUI 提供下拉框，默认值设为系统Charset.defaultCharset()
支持正则匹配和上下文行输出
纯字符串搜索不够用，用户常需要“显示匹配行前后各 2 行”。这时不能只用 lines().filter()，得维护一个滑动窗口队列。
- 用
LinkedList<string></string>缓存最近 N 行，每次新读一行就addLast()并removeFirst()（若超限） - 匹配命中时，遍历队列输出，用
indexOf()定位当前行为基准，再取get(i-2)到get(i+2) - 正则用
Pattern.compile(regex, Pattern.CASE_INSENSITIVE)，避免每次line.matches()重复编译——尤其在循环内
避免内存爆炸：大文件必须用流式 + 行号控制
有人把整个文件读进 String 再 split("\n")，1GB 文件直接 OOM。真实工具必须边读边判，且限制最大扫描行数防卡死。
立即学习“Java免费学习笔记（深入）”；
- 用
lines().limit(10_000_000)设硬上限，超过后抛出自定义异常提示“文件过大，已跳过后续内容” - 记录当前行号用
AtomicLong或lines().forEachOrdered((line, index) -> {...})（后者需用IntStream.range(0, ...)配合） - 如果用户要高亮显示，别用
String.replace()，改用Matcher.appendReplacement()防止正则元字符误替换
Path path = Paths.get("access.log");
Pattern pattern = Pattern.compile("404|500", Pattern.CASE_INSENSITIVE);
try (Stream<String> lines = Files.lines(path, StandardCharsets.UTF_8)) {
AtomicInteger lineNumber = new AtomicInteger(1);
lines
.map(line -> new AbstractMap.SimpleEntry<>(lineNumber.getAndIncrement(), line))
.filter(entry -> pattern.matcher(entry.getValue()).find())
.limit(100)
.forEach(entry -> System.out.printf("[%d] %s%n", entry.getKey(), entry.getValue()));
}
文件编码和行缓冲策略是实际交付中最容易被跳过的环节，尤其是混合编码日志和 Windows / Linux 换行符混用时，光靠“能跑通”测试用例会埋坑。 
