Java中为何用二进制流FileInputStream读取config.properties而非FileReader？

这个问题问到点子上了！在Java里处理.properties配置文件时，选择InputStream还是Reader，核心差异在编码控制和API的历史设计，下面给你拆解清楚：

1. 编码控制的安全性 #

.properties文件的官方规范是使用**ISO-8859-1（Latin-1）**编码，虽然现在很多人会用UTF-8写配置，但直接用FileReader会踩坑：

• FileReader默认使用系统平台的字符集（比如Windows是GBK，Linux是UTF-8），如果配置文件编码和系统默认编码不一致，读取非ASCII字符（比如中文、特殊符号）时必然会乱码。
• 而用FileInputStream的话，你可以主动通过InputStreamReader指定编码，完全可控，不会因为系统环境不同出问题，示例代码如下：

  Properties props = new Properties();
  try (InputStreamReader reader = new InputStreamReader(
          new FileInputStream("config.properties"), StandardCharsets.UTF_8)) {
      props.load(reader);
  }
  

  就算直接用props.load(inputStream)加载流，Properties也会按ISO-8859-1解析，完全符合官方规范。

2. API设计的历史原因 #

早期JDK（1.5及之前）的Properties类只有load(InputStream)方法，没有load(Reader)重载。直到JDK1.6才新增了基于Reader的方法，所以很多老代码、传统教程里都会习惯用FileInputStream读配置，这是历史遗留的写法，放到现在依然是更稳妥的选择。

3. 二进制流的通用性 #

虽然.properties是文本文件，但本质上它是字节序列。用InputStream读取可以跳过字符编码转换的中间步骤，要是你需要对配置文件做二进制层面的处理（比如校验、加密），InputStream也会更灵活。

总结一下：如果想严格控制编码、兼容老代码或者追求更通用的字节流处理，用FileInputStream（配合InputStreamReader指定编码）是更靠谱的选择；直接用FileReader会依赖系统默认编码，很容易出现跨环境的乱码问题。

内容的提问来源于stack exchange，提问作者sake