FileReader 使用系统默认编码且不可配置，本质是 InputStreamReader 的快捷封装；其编码由操作系统决定，跨平台易乱码，需用 InputStreamReader 显式指定字符集。
FileReader 本身不接受字符集参数，它内部直接使用 系统默认编码（即 Charset.defaultCharset() 的返回值）来解码字节流。这个机制不是“可配置的默认值”，而是硬编码在构造逻辑里的固定行为。
为什么 FileReader 没有字符集参数？
因为它的设计定位就是“便捷类”——Java 官方文档明确说明：“它假设默认编码和默认缓冲区大小是合适的；如需自定义，请用 InputStreamReader 包装 FileInputStream”。所以 FileReader 的所有构造函数都只传文件路径或 File 对象，底层始终调用：
new InputStreamReader(new FileInputStream(file), Charset.defaultCharset())
也就是说，它本质上是 InputStreamReader 的一个“带默认编码的快捷封装”，而非独立支持编码切换的完整实现。
系统默认编码从哪来？
它由 JVM 启动时读取操作系统环境决定，常见情况如下：
- Windows 中文系统：通常是
GBK（或GB18030） - macOS / Linux：通常是
UTF-8 - 可通过
Charset.defaultCharset().name()在运行时打印确认
注意：这个值与源文件真实编码无关。如果文件是 UTF-8 编码，而系统默认是 GBK，用 FileReader 直接读就会出现乱码——这不是 bug，而是机制使然。
它和 InputStreamReader 的关键区别在哪？
根本差异在于构造能力：
-
FileReader：只有无参/单参构造器，无法指定字符集 -
InputStreamReader：提供带Charset或String charsetName的构造器，可显式控制解码方式
所以当你看到 “FileReader 使用默认编码”，其实是在说：它把选择权交给了操作系统，且不给你修改的机会。这不是灵活性不足，而是设计上就要求你——如果编码不确定或不匹配，默认类就不适用。
实际影响有哪些？
最典型的问题场景：
- 跨平台部署：同一段用 FileReader 读文件的代码，在 Windows 开发、Linux 部署时可能突然乱码
- 读取带 BOM 的 UTF-8 文件：系统默认为 GBK 时，BOM 字节会被错误解释成汉字，开头多出乱码字符
- 读取 ISO-8859-1 编码的英文配置文件：在 UTF-8 系统下可能误将某些字节组合解析为代理对，导致异常
这些问题都无法靠调整 FileReader 自身解决，必须换用 InputStreamReader 显式指定编码。
