如何在 Java 中通过 Files.readAllLines() 快速获取文件所有内容并按行存储到列表

如何在 Ja va 中通过 Files.readAllLines() 快速获取文件所有内容并按行存储到列表

Files.readAllLines() 读取文件后，为什么返回的 List 每行末尾没有换行符？

这事儿其实挺容易让人困惑的：明明读的是文件，怎么拿到的列表里，每行末尾的换行符都不见了？

答案是，这正是 Files.readAllLines() 的设计本意。它的底层实现依赖 BufferedReader.readLine()，而这个方法的核心逻辑就是按“逻辑行”切分，并且会“顺手”帮你剥离掉行尾的 \n、\r\n 或 \r。所以，你拿到的是一个干净的字符串列表，每项都不带换行符——这并非程序出了bug，而是预期的标准行为。

那么，如果你后续需要将内容拼接回原始文本格式（比如写回另一个文件），就得自己动手把换行符补回去。常用的方法是 String.join("\n", lines)。当然，这里有个细节需要注意：换行符的选择得看目标平台，比如在Windows环境下，通常得用 "\r\n"。

中文乱码或特殊字符出错，该怎么指定编码？

编码问题，堪称Ja va文件操作里的“经典陷阱”。如果不显式指定编码会怎样？在Ja va 11及之后的版本中，默认会使用 StandardCharsets.UTF_8；但在Ja va 8等老版本里，则会调用 Charset.defaultCharset()，这个默认编码完全依赖于系统环境。想象一下，在Linux服务器上读取一个由Windows系统生成的GBK编码文件，十有八九会抛出令人头疼的 MalformedInputException。

所以，最佳实践是务必显式传入编码参数：

立即学习“Ja va免费学习笔记（深入）”；

// 推荐使用 UTF-8
List lines = Files.readAllLines(Paths.get("data.txt"), StandardCharsets.UTF_8);
// 仅在处理遗留系统文件时，才考虑使用 GBK
List lines = Files.readAllLines(Paths.get("log.txt"), Charset.forName("GBK"));

• 优先使用常量：尽量使用 StandardCharsets 类中定义的常量（如 UTF_8），避免因手误拼错字符串。
• 告别默认依赖：永远不要依赖 defaultCharset()，CI/CD流水线的环境与开发人员的本地机器，编码设置常常不一致。
• 先判断，后操作：如果不确定源文件的编码格式，可以先用 file -i filename（Linux/macOS）命令，或者借助VS Code等编辑器的编码检测功能来辅助判断。

大文件用 readAllLines() 会 OOM 吗？什么规模算“大”？

答案是肯定的，而且风险不小。Files.readAllLines() 的工作方式是将整个文件的所有行一次性全部加载到堆内存中。这不仅意味着要为每一行创建一个 String 对象，还要加上 ArrayList 内部数组的开销。实际算下来，内存占用通常是原始文件体积的2到5倍。

那么，多大的文件算“大”呢？这里有个经验性的参考阈值：

• ≤ 10 MB：通常比较安全（假设JVM堆内存至少为256 MB）。
• 10–100 MB：需要谨慎，尤其要关注行数。如果文件里每行都很短（比如CSV文件，每行只有100个字符），一个100万行的文件可能体积只有100MB，但产生的对象数量极其庞大，会给垃圾回收（GC）带来巨大压力。
• > 100 MB：强烈建议改用流式处理方式，例如使用 Files.lines()，或者用传统的 BufferedReader 手动逐行读取。

举个反面例子：在处理日志分析时，如果写成 Files.readAllLines().stream().filter(...)，就相当于先把整个日志文件全部塞进内存，然后再进行过滤。这无疑是效率最低的做法，完全失去了流式处理的意义。

路径不存在或没权限时，抛什么异常？怎么提前兜住？

程序可不会静默失败。在这种情况下，Files.readAllLines() 会直接抛出 IOException 的子类，例如 NoSuchFileException（路径不存在）、AccessDeniedException（权限不足），或者因安全管理器拦截而抛出的 SecurityException。

更稳健的做法，是在读取之前就进行前置检查：

Path path = Paths.get("config.properties");
// 检查文件是否存在
if (!Files.exists(path)) {
    throw new IllegalArgumentException("配置文件不存在: " + path);
}
// 检查文件是否可读
if (!Files.isReadable(path)) {
    throw new IllegalArgumentException("配置文件不可读: " + path);
}
// 通过检查后再执行读取操作
List lines = Files.readAllLines(path, StandardCharsets.UTF_8);

值得注意的是，Files.exists() 和 Files.isReadable() 属于轻量级调用，比直接通过try-catch捕获异常能更早地暴露问题，也便于在日志中精准定位故障点。

不过，这里还有一个容易被忽略的“坑”：符号链接循环和NFS挂载点超时。这两种情况可能导致 exists() 检查被挂起数秒之久。对于生产环境的关键应用，需要考虑为这些检查操作增加超时控制机制（这通常需要自行封装工具方法，或者换用 Files.walkFileTree() 配合 SimpleFileVisitor 来实现）。