如何在 Java 中读取一个简单的文本文件（使用 FileReader）

FileReader读中文会乱码，因其默认使用平台编码（Windows为GBK，Linux/macOS多为UTF-8），不支持显式指定编码，导致UTF-8文件在GBK环境解码失败；必须改用InputStreamReader包装FileInputStream并传入"UTF-8"，且需try-with-resources确保流关闭。

一句话总结：FileReader 适合读取纯文本，但必须注意编码和资源释放，否则容易乱码或文件句柄泄漏。

为什么 FileReader 读中文会乱码？

问题的根源在于，FileReader 是基于平台默认编码的字符流，它不支持你显式指定编码（比如 UTF-8）。这就埋下了一个跨平台的“暗雷”：Windows 的默认编码通常是 GBK，而 Linux/macOS 则多为 UTF-8。想象一下，一个用 UTF-8 保存的文件，在 Windows 上被 FileReader 直接读取，虽然程序可能不会抛出 IOException，但输出的内容大概率会变成一堆乱码。

这里有几个关键点需要牢记：

• 千万不要依赖 FileReader 来处理包含中文、emoji 或需要跨平台分发的文本文件。
• 真正可控且安全的做法，是使用 InputStreamReader 包装 FileInputStream，并明确传入 "UTF-8" 等编码参数。
• 只有在一种情况下，FileReader 才勉强可用：你确定文件内容全是 ASCII 字符（比如日志 ID、配置键名），并且运行环境的编码是统一的。

如何安全地用 FileReader 读一行？

FileReader 本身并不提供按行读取的能力，你必须配合 BufferedReader 来使用。如果单独创建一个 new FileReader("a.txt")，你只能逐字符读取，效率低下且容易出错。

正确的组合方式是这样的：new BufferedReader(new FileReader("a.txt"))。

使用时务必注意：

• 调用的是 readLine() 方法，而不是 read()。后者返回的是 int 类型，需要手动转换，还容易漏掉处理换行符的逻辑。
• 当遇到空行时，readLine() 会返回一个空字符串 ""，而不是 null；只有当读取到文件末尾时，它才会返回 null。这个细节是很多新手容易混淆的地方。

不关流会怎样？

FileReader 和 BufferedReader 都属于资源型对象，底层持有着操作系统的文件句柄。如果不主动关闭，会引发一系列问题：

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

• 在 Windows 系统下，可能导致文件无法被删除或重命名，系统会提示“进程正在使用”。
• 如果程序需要大量读取文件，未关闭的句柄会不断累积，最终触发 ja va.io.IOException: Too many open files 错误。
• 即便 JVM 进程退出，这些句柄也不一定会被立即释放，这对于需要长期运行的服务来说是个隐患。

因此，最推荐的写法是使用 Ja va 7 引入的 try-with-resources 语法：

try (BufferedReader br = new BufferedReader(new FileReader("data.txt"))) {
    String line;
    while ((line = br.readLine()) != null) {
        System.out.println(line);
    }
}

这样，无论代码块正常执行还是发生异常，br 及其包装的 FileReader 都会被自动关闭，无需手动干预。

说到底，使用 FileReader 本质上是一种妥协——它用省去一行构造代码的便利，换来了编码和资源管理上的潜在风险。如果真要读取文本文件，优先考虑 Files.readAllLines(Paths.get("x.txt"), StandardCharsets.UTF_8) 这种更现代、更安全的方式；如果非要进行流式读取，那就老老实实地使用 InputStreamReader 并显式指定编码。这才是稳妥的做法。