Reader和Writer是字符流的输入/输出端，方向相反、不可互换；Reader.read()返回int表示字符或EOF，Writer.write()只取低16位；必须注意编码一致、使用缓冲及追加模式需显式指定。
Reader 和 Writer 是字符流的输入/输出两面，本质对称但方向相反
Reader 专管“读”——从文件、字符串、网络等源中按字符单位提取文本；Writer 专管“写”——把字符（char、char[]、String）按指定编码写入目标。它们不是互换的，也不能混用：FileReader 不能写，FileWriter 不能读。
关键区别在于数据流向和方法签名：
-
Reader.read()返回int（0–65535 表示有效字符，-1 表示 EOF），不是byte或char—— 强转成(char)才能打印 -
Writer.write(int c)只取参数低 16 位，高位被丢弃；传入'A'或65效果一样，但传0x10041就只写0x0041 - 两者都继承自
AutoCloseable，推荐用 try-with-resources，否则容易漏关流导致文件句柄泄漏
为什么不能用字节流直接处理中文？乱码根源在这里
字节流（如 FileInputStream）一次读 1 字节，而中文在 UTF-8 中占 3 字节、GBK 中占 2 字节。若强行把每个字节 (char)byte 强转输出，就会拆断多字节字符，出现 ??ú 这类乱码。
字符流自动完成编码转换：构造 FileReader 时，默认用系统默认编码（Windows 常为 GBK，Linux/macOS 常为 UTF-8）解码字节；FileWriter 则用相同编码把字符编码成字节再写盘。所以：
立即学习“Java免费学习笔记（深入）”；
- 不显式指定编码时，
FileReader("a.txt")和FileWriter("b.txt")编码必须一致，否则读写错位 - 跨平台或需统一编码时，**别用
FileReader/FileWriter**，改用InputStreamReader(new FileInputStream(f), "UTF-8")和OutputStreamWriter(new FileOutputStream(f), "UTF-8") - Java 11+ 支持
Files.newBufferedReader(path, StandardCharsets.UTF_8)，更安全简洁
read(char[] buf) 和 read() 单字符读取，性能差十倍以上
用 reader.read() 循环逐个读字符，看似简单，实则每次调用都触发底层 I/O 系统调用，开销极大。而 reader.read(char[] buf) 一次批量读入（比如 1024 个字符），大幅减少系统调用次数。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
实操建议：
- 永远优先使用带缓冲的版本：
BufferedReader包裹FileReader，或直接用Files.lines(path)流式处理行 - 手动分配
char[]时，长度建议设为 1024 或 8192，太小起不到缓冲作用，太大浪费堆内存 - 注意
read(char[] buf)返回的是**实际读到的字符数**，不是数组长度，必须用返回值截取有效内容：new String(buf, 0, len)
FileWriter 默认会覆盖文件，追加写必须显式传 true
FileWriter(String name) 构造器默认以“覆盖模式”打开文件，已有内容直接清空。这不是 bug，是设计如此 —— 但极易误操作导致数据丢失。
追加写必须这样写：
FileWriter fw = new FileWriter("log.txt", true); // 第二个参数 true 表示 append
或者更现代的方式：
Files.write(Paths.get("log.txt"), "new line\n".getBytes(StandardCharsets.UTF_8),
StandardOpenOption.CREATE, StandardOpenOption.APPEND);
另外注意：FileWriter 没有 writeLine() 方法，换行要自己加 "\n" 或用 BufferedWriter.newLine()。
字符流的核心就三点：方向别反、编码别错、缓冲别省。最容易被忽略的是编码一致性——同一份文件，用不同编码的 Reader 打开，结果可能天差地别，且毫无报错提示。
