Java 标准库在 NIO.2（Java 7 引入）中提供了 Files 工具类，其中 newBufferedReader() 方法为文本文件读取提供了一个现代且简洁的入口。与传统的 FileReader 或者手动包装 InputStreamReader 相比，这个方法直接返回一个 BufferedReader，既支持显式指定字符编码，又能利用缓冲机制减少磁盘 IO 次数。对于需要按行处理配置文件、日志文件或普通文本的场景，它比直接操作字节流更符合文本语义，也比遗留的 java.io 类更加健壮。
一、为什么选择 Files.newBufferedReader()
在 Java 7 之前，读取文本文件的常见做法是使用 FileReader。但 FileReader 有一个明显的缺陷：它使用平台默认字符编码来解码字节，这意味着同一段代码在 Windows 和 Linux 上可能得到完全不同的结果。如果文件本身是 UTF-8 编码，而平台默认编码是 GBK 或 Windows-1252，读取出来的字符串就会乱码。开发者往往需要在外面再包一层 InputStreamReader，并手动传入 StandardCharsets.UTF_8，代码量迅速增加，而且容易在匆忙中漏掉编码参数。
另一种传统做法是把 FileInputStream 包装成 InputStreamReader，再包装成 BufferedReader，形成三层嵌套。功能上没有问题，但从可读性角度看，这种链式构造暴露了过多底层细节，让简单的读取任务显得笨重。Files.newBufferedReader() 的出现正是为了解决这个矛盾。它的内部使用了 NIO 的 FileChannel 以及 Channels.newReader() 方法，把字节通道和字符解码器组合起来，对外只返回一个 BufferedReader。也就是说，你获得的仍然是熟悉的字符流接口，但底层已经走上了现代 NIO 的文件通道。
从设计角度看，Files.newBufferedReader() 与 Path、Paths 配合使用，能够让文件位置、编码、缓冲策略都集中在一行代码里表达清楚。对于日常开发中的日志分析、配置文件加载、CSV 解析等场景，这种方法既减少了出错可能，又保持了代码的整洁。下面这段对比可以直观看出新旧写法的差异。
// 传统组合方式：需要手动包装两层，还要记得指定编码
try (BufferedReader reader = new BufferedReader(
new InputStreamReader(new FileInputStream("data.txt"), StandardCharsets.UTF_8))) {
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
}
// Files.newBufferedReader 方式：代码更短，意图更明确
Path path = Paths.get("data.txt");
try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
}
二、基础用法与编码设置
Files.newBufferedReader() 有三个重载版本。最简单的版本只接收一个 Path 参数，在 Java 11 及以后的版本中默认使用 UTF-8 编码；但在更早的 Java 版本中，它的默认编码仍然是平台相关。正因为这个历史差异，实际项目中建议始终显式传入 Charset 参数，比如 StandardCharsets.UTF_8，以保证跨平台行为一致。第二个版本接收 Path 和 Charset，第三个版本在此基础上增加了缓冲区大小的整数参数。
使用 StandardCharsets.UTF_8 是当前最通用的选择，但如果你的文件是其他编码，例如 GBK、ISO-8859-1 或 UTF-16，也可以直接传入对应的 Charset 对象。注意不要把编码名称写成字符串再转换，那样会增加不必要的开销，直接使用 StandardCharsets 中的常量更高效、更不易拼错。
资源管理方面，Files.newBufferedReader() 返回的 BufferedReader 实现了 AutoCloseable 接口，因此强烈建议放入 try-with-resources 块中。这样无论是正常读完还是中途抛出异常，文件句柄都能被自动释放。下面是一个完整的读取示例，包含导入和路径处理。
import java.io.BufferedReader;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
public class ReadTextFile {
public static void main(String[] args) {
Path file = Paths.get("C:\\Users\\docs\\article.txt");
try (BufferedReader reader = Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
} catch (IOException e) {
System.err.println("读取失败: " + e.getMessage());
}
}
}
代码中的路径使用了 Windows 反斜杠转义形式，实际指向 C:\Users\docs\article.txt。如果你使用的是 Unix 或 macOS，可以换成 /home/user/docs/article.txt 这样的正斜杠路径。关键点在于无论路径格式如何，Paths.get() 都能正确解析，Files.newBufferedReader() 不需要关心底层文件系统细节。
三、与 Stream 结合按行处理
BufferedReader 除了提供传统的 readLine() 方法外，还提供了一个 lines() 方法，返回 Stream<String>。这个流是惰性的，每调用一次终端操作，才会逐行从文件中读取数据，不会一次性把整个文件加载到内存中。对于日志分析、数据过滤、统计行数等任务，这种函数式写法非常方便。例如统计日志中包含 ERROR 的行数，可以用下面这段代码完成。
Path path = Paths.get("application.log");
try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
long errorLines = reader.lines()
.filter(line -> line.contains("ERROR"))
.count();
System.out.println("错误行数: " + errorLines);
} catch (IOException e) {
e.printStackTrace();
}
需要注意的是，lines() 返回的流与创建它的 BufferedReader 是绑定的，流关闭时会同时关闭底层的 reader，反之亦然。因此，务必把流的使用放在 try-with-resources 块内部完成。如果把流保存到外部并在 reader 关闭后再操作，很可能会抛出 IOException。例如下面这个错误示例就展示了提前关闭 reader 导致流操作失败的情况。
// 错误示例：提前关闭 reader 后再操作流，可能引发 IOException
BufferedReader reader = Files.newBufferedReader(Paths.get("data.txt"));
Stream<String> stream = reader.lines();
reader.close(); // 这里关闭了底层资源
stream.forEach(System.out::println); // 运行时可能报错
还需要注意，虽然 lines() 用起来简洁，但如果你的处理逻辑需要根据当前行号做复杂控制，或者需要在循环中提前终止并返回某些状态，使用传统的 readLine() 循环可能更直观。流式处理更适合过滤、映射、聚合这类无状态操作，不适合需要在遍历过程中修改文件内容或依赖外部可变状态的场景。
四、缓冲区大小与性能调优
Files.newBufferedReader() 默认使用的缓冲区大小是 8192 字节，也就是 8KB。对于大多数文本文件，这个大小已经足够平衡内存占用和系统调用次数。但当文件特别大或者每一行特别长时，增大缓冲区可以减少读取磁盘的次数，从而提升顺序读取的吞吐量。第三个重载版本允许传入自定义缓冲区大小，例如 16KB 或 32KB。
Path path = Paths.get("large.txt");
int bufferSize = 16 * 1024; // 16 KB
try (BufferedReader reader = Files.newBufferedReader(
path, StandardCharsets.UTF_8, bufferSize)) {
reader.lines()
.map(String::trim)
.filter(line -> !line.isEmpty())
.forEach(System.out::println);
} catch (IOException e) {
e.printStackTrace();
}
缓冲区的本质是用空间换时间：每次从文件通道读取更多数据到内存，再由字符解码器逐步消费，减少底层 read() 系统调用的频率。不过缓冲区也不是越大越好，过大的缓冲区会占用更多堆内存，对于小文件来说反而带来不必要的分配开销。一般场景下保持默认值即可，只有在处理几百 MB 甚至更大的文本文件时，把缓冲区提升到 16KB 或 32KB 才可能带来可感知的改进。
如果文件极大且只需要顺序扫描，也可以考虑使用 Files.readAllLines() 或 Files.lines()，但它们的内部实现与 newBufferedReader() 并不完全相同。readAllLines() 会把所有行放入一个 List，内存占用与文件大小成正比，不适合大文件。而 Files.lines() 直接返回 Stream<String>，内部同样使用缓冲读取，但在关闭资源方面需要额外注意。相比之下，手动创建 BufferedReader 可以更明确地控制缓冲区大小和关闭时机，适合对资源管理要求严格的场景。
五、常见错误与注意事项
第一个常见错误是编码不匹配。如果你在 Files.newBufferedReader() 中指定了错误的字符集，读取出来的字符串会产生乱码，而且这种错误通常不会立即抛出异常，而是静默地污染后续处理逻辑。因此在读取任何外部文件前，先确认文件的真实编码，并显式传入对应 Charset。如果不确定编码，可以使用一些第三方库进行探测，但不要依赖平台默认值。
第二个问题是资源泄漏。虽然 BufferedReader 实现了 AutoCloseable，但如果你忘记放在 try-with-resources 中，或者在一个长生命周期的对象中持有 reader 而没有及时关闭，文件句柄会被一直占用，导致其他进程无法删除或修改该文件。在 Linux 系统上，进程可同时打开的文件描述符数量有限，泄漏严重时甚至会影响整个服务的稳定性。
第三个容易忽视的点是换行符差异。Windows 使用 \r\n，Unix 使用 \n，老式 Mac 使用 \r。readLine() 会把这些行终止符全部视为行结束，但返回的字符串不会包含终止符本身。如果你的业务逻辑依赖原始行内容（例如需要保留行尾空白），那么逐字符读取或者使用字节流可能更合适。好在绝大多数文本处理场景中，丢失换行符并不会造成问题。
最后，不要在大文件上使用 readAllLines() 来代替 newBufferedReader()。readAllLines() 会把整个文件读入内存，虽然代码更短，但遇到几百 MB 的日志文件很容易触发 OutOfMemoryError。正确做法是使用 Files.newBufferedReader() 获取逐行读取能力，再配合 lines() 流式处理，既能控制内存，又能写出清晰的函数式代码。
Java NIOFiles.newBufferedReader字符流修改时间：2026-09-28 08:19:06