reader专用于读、writer专用于写，因接口契约无对应方法且io分层隔离，故不可互换；filereader/filewriter默认编码依赖系统，易致乱码，须用inputstreamreader/outputstreamwriter显式指定standardcharsets.utf_8；缓冲能大幅提升性能，bufferedreader的readline()是文本处理关键。
Reader 和 Writer 是一对抽象基类，分工明确：Reader 专用于读取字符，Writer 专用于写入字符。它们不是互为反向操作的“镜像”，而是从设计上就分离了输入与输出职责，且各自方法签名、异常行为、缓冲策略都不同——直接混用或误认为可互相替代，是初学者最常踩的坑。
为什么不能用 Reader 写数据，也不能用 Writer 读数据？
这是由接口契约决定的：Reader 只定义了 read()、read(char[]) 等输入方法，没有 write()；Writer 只有 write()、flush()、close()，没有 read()。编译器会直接报错，比如：
Reader r = new FileReader("a.txt");
r.write('x'); // ❌ 编译错误：cannot resolve method 'write(char)'更深层原因是：Java 的 IO 分层模型中，输入流（Reader/InputStream）和输出流（Writer/OutputStream）属于不同分支，不可跨支调用。强行“倒着用”在语义和实现上都不成立。
FileReader 和 FileWriter 的默认编码有多危险？
这两个类的无参构造函数（如 new FileReader("a.txt")）会使用 Charset.defaultCharset()，也就是操作系统当前默认编码（Windows 上通常是 GBK，Linux/macOS 多为 UTF-8）。一旦读写两端编码不一致，中文立刻变 ??? 或乱码字节。
立即学习“Java免费学习笔记（深入）”；
- 写入时用
FileWriter默认编码（GBK），读取时用BufferedReader指定UTF_8→ 乱码 - 文件本身是 UTF-8 编码，但用
FileReader直接打开 → 读出的中文字符被截断或替换为 - 跨平台部署时，同一段代码在开发机（UTF-8）和生产服务器（GBK）行为不一致
✅ 正确做法：显式传入 StandardCharsets.UTF_8，绕过默认编码：
Reader r = new InputStreamReader(new FileInputStream("a.txt"), StandardCharsets.UTF_8);
Writer w = new OutputStreamWriter(new FileOutputStream("b.txt"), StandardCharsets.UTF_8);注意：FileReader/FileWriter 本身不支持指定编码（构造函数无 charset 参数），必须升一级用 InputStreamReader/OutputStreamWriter。
缓冲为什么不能省？BufferedReader 和 BufferedWriter 怎么配对用？
逐字符读写（Reader.read() / Writer.write(int)）会频繁触发系统调用，性能极差；而 BufferedReader 和 BufferedWriter 在内存中维护缓冲区，一次批量读/写几十 KB，吞吐量可提升 10 倍以上。
-
BufferedReader提供readLine()—— 这是处理文本文件最常用的方法，自动识别\n、、<code>\r -
BufferedWriter提供newLine()—— 它会写入当前平台的换行符（Windows 是\r\n，其他多为\n），比手动写"\n"更可靠 - 二者必须成对使用：用
BufferedReader包装带编码的InputStreamReader，用BufferedWriter包装带编码的OutputStreamWriter
✅ 推荐组合（带资源自动关闭）：
try (BufferedReader br = new BufferedReader(
new InputStreamReader(new FileInputStream("in.txt"), StandardCharsets.UTF_8));
BufferedWriter bw = new BufferedWriter(
new OutputStreamWriter(new FileOutputStream("out.txt"), StandardCharsets.UTF_8))) {
String line;
while ((line = br.readLine()) != null) {
bw.write(line.toUpperCase());
bw.newLine();
}
}资源不关、异常不处理，Reader/Writer 就会“咬人”
忘记 close() 会导致文件句柄泄漏，尤其在高并发或长期运行服务中，可能触发 java.io.IOException: Too many open files；而未捕获 IOException 会让程序在读写失败时直接崩溃，且流未关闭。
✅ 唯一稳妥做法：用 try-with-resources —— 它要求资源类型实现 AutoCloseable（Reader 和 Writer 都满足）：
try (Reader r = new InputStreamReader(is, UTF_8);
Writer w = new OutputStreamWriter(os, UTF_8)) {
// 使用 r 和 w
} // ✅ 自动调用 close()，无论是否异常别信“JVM 会帮你关”——它不会。也别用 finally 手动关，容易因二次关闭或空指针引发新异常。
真正的麻烦往往不在“怎么读写”，而在“谁来管编码、谁来管缓冲、谁来关流”。这三个点没对齐，哪怕逻辑再简单，也会在某次上线后凌晨三点弹出乱码告警。
