Reader和Writer是处理字符的抽象类，需通过InputStreamReader等子类指定编码（如UTF-8），配合BufferedReader/BufferedWriter提升性能并确保flush/close，否则易乱码或数据丢失。
Reader和Writer是字符流，不是字节流
Java中Reader和Writer专用于处理字符（char），底层自动处理字符编码转换；而InputStream和OutputStream操作的是原始字节（byte）。如果你读写文本文件却误用字节流，遇到中文就容易乱码——这不是流本身的问题，而是没经过正确的字符解码/编码步骤。
关键区别在于：
- Reader的read()方法返回int（表示一个char，范围0–65535），-1表示流末尾
- Writer的write(int)接收一个char值，write(String)或write(char[])更常用
- 它们都必须指定字符集（如UTF-8），否则依赖JVM默认编码（file.encoding），跨环境极易出问题
为什么不能直接new Reader或Writer
Reader和Writer都是抽象类，不能实例化。常见子类有：FileReader/FileWriter、InputStreamReader/OutputStreamWriter、StringReader/StringWriter。
注意陷阱：
- FileReader和FileWriter不接受字符集参数，强制使用系统默认编码，生产环境应避免使用
- 正确做法是组合字节流与转换流：new InputStreamReader(new FileInputStream("a.txt"), "UTF-8")
- OutputStreamWriter同理，是把字符转字节的关键桥梁，缺它就无法控制编码
read()和write()的阻塞行为与缓冲必要性
所有Reader/Writer子类的read()和write()方法默认是阻塞的，且单次调用开销大。比如逐字符读取一个大文件，不用缓冲会严重拖慢性能。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
推荐组合方式：
- 用BufferedReader包装InputStreamReader，支持readLine()和内部缓冲
- 用BufferedWriter包装OutputStreamWriter，避免每次write()都触发底层IO
- 切记：BufferedWriter必须调用flush()或close()，否则内容可能滞留在缓冲区不落地
BufferedReader br = new BufferedReader(
new InputStreamReader(new FileInputStream("log.txt"), "UTF-8"));
String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
br.close(); // 不关流，缓冲区残留数据可能丢失字符流异常处理中的编码一致性
同一个文件，用UTF-8写入，却用GBK读取，必然乱码。这种错误不会抛异常，只会输出不可读字符——排查时容易误判为数据损坏。
立即学习“Java免费学习笔记（深入）”；
实际开发中要注意：
- 配置文件、日志、HTTP响应体等明确标注字符集的地方，代码里必须严格对应
- 使用Files.newBufferedReader(Path, Charset)比手动套娃更安全，API设计已规避默认编码陷阱
- Writer子类中，只有OutputStreamWriter和FileWriter（Java 11+重载构造）支持显式传Charset，其他如StringWriter不涉及编码，无需指定
字符流的核心不在“读写”动作本身，而在编码意图的显式表达。漏掉Charset参数、混用默认编码、忘记flush()或close()，这三处最容易导致线上文本处理出人意料的结果。
