reader和writer是字符流，负责自动处理字符编码转换；inputstream和outputstream是字节流，不涉及编码。filereader/filewriter默认使用系统编码，易致乱码，应改用inputstreamreader/outputstreamwriter并显式指定charset。
Reader 和 Writer 是字符流，不是字节流
Java 的 Reader 和 Writer 是专门处理**字符（char）**的抽象基类，底层自动处理字符编码转换；而 InputStream 和 OutputStream 处理的是原始字节（byte）。如果你用 FileInputStream 读中文文本却没指定编码，大概率出现乱码——这不是数据坏了，是没走字符流该走的解码路径。
关键区别在于：所有 Reader 子类（如 FileReader、BufferedReader）内部都持有 CharsetDecoder，会把从字节流中读出的字节按指定编码（默认系统编码，常为 UTF-8 或 GBK）转成 Java 的 Unicode 字符（char）；Writer 则反向做编码。
FileReader / FileWriter 默认用系统编码，极易出错
这是最常踩的坑：FileReader 和 FileWriter 的构造函数**不接受 Charset 参数**，只能用系统默认编码。一旦源文件是 UTF-8 编码但系统是 Windows-1252（比如某些旧版 Windows），读出来就是乱码；写入时也一样，你以为写了 UTF-8，实际存的是系统编码。
- ✅ 正确做法：绕过
FileReader/FileWriter，改用InputStreamReader+FileInputStream或OutputStreamWriter+FileOutputStream - ✅ 显式传入
StandardCharsets.UTF_8，避免隐式依赖系统环境 - ⚠️ 注意：
FileReader的 Javadoc 明确写着：“The constructors of this class assume that the default character encoding and the default byte-buffer size are appropriate.” —— 这句话等于在提醒你：别信它
try (Reader reader = new InputStreamReader(
new FileInputStream("data.txt"), StandardCharsets.UTF_8);
Writer writer = new OutputStreamWriter(
new FileOutputStream("out.txt"), StandardCharsets.UTF_8)) {
int c;
while ((c = reader.read()) != -1) {
writer.write(c);
}
}
BufferedReader.readLine() 会丢掉换行符，且不识别 \r\n 以外的行终止符
BufferedReader.readLine() 返回的字符串**不含任何换行符（\n、\r 或 \r\n）**，这点和 Python 的 file.readline() 行为一致，但容易被忽略。更隐蔽的问题是：它只识别 \n、 和 <code>\r\n，对 Unicode 换行符（如 \u2028、\u2029）或旧 Mac 的 \r 单独出现的情况，可能切不断行或吞掉内容。
立即学习“Java免费学习笔记（深入）”；
- 如果需要保留换行符，别用
readLine()，改用read(char[])或readLine()后手动拼接 - 跨平台处理文本时，建议统一用
System.lineSeparator()写入，而不是硬写"\n" -
readLine()返回null表示流末尾，不是空行；空行返回的是空字符串""
Writer 不自动 flush，不 close 就可能丢数据
所有带缓冲的 Writer（如 BufferedWriter、PrintWriter）都会攒一批字符再批量写入底层流。如果你只 write() 但没 flush() 或 close()，最后几个字符可能一直卡在缓冲区里，文件里看不到。
- ✅ 最稳妥：用 try-with-resources，
close()会自动触发flush() - ✅ 需要实时可见（比如日志），调用
writer.flush()，但别滥用——频繁 flush 会显著拖慢性能 - ⚠️
PrintWriter构造时可传autoFlush = true，但仅对println()、printf()、format()生效，write()仍需手动 flush
字符流的核心约束很实在：它省去了你手动编解码的麻烦，但也把编码责任从“我来转”变成了“我得选对”。一旦漏掉 Charset、误用 FileReader、忘了 flush 或默认换行逻辑，问题就藏在看似最简单的那几行代码里。
