字符流本身不管理缓冲区和编码，缓冲由BufferedReader/Writer提供（默认8192字符），编码由InputStreamReader/OutputStreamWriter负责，二者分工明确、协同工作。
Java 字符流（Reader/Writer 及其子类）本身不直接管理缓冲区大小，也不内置编码逻辑；所谓“默认缓冲区”和“编码”其实是两个独立但协同工作的机制——一个负责性能优化，一个负责字节与字符的转换。理解它们的关系，关键在于分清“谁在管什么”。
字符流的缓冲区是处理流加的，不是 Reader/Writer 自带的
基础字符流如 FileReader、FileWriter 本身没有缓冲区，每次读写都可能触发底层 I/O 调用，效率低。真正提供缓冲能力的是处理流：
-
BufferedReader和BufferedWriter在内部维护一个char[]数组（默认大小 8192 字符），用于批量读取或暂存数据 - 这个缓冲区只操作
char，完全不知道字节、编码、UTF-8 或 GBK 是什么 - 它只是让
read(char[])或write(char[], int, int)更快，不改变字符语义
编码发生在“字节 ↔ 字符”的边界，不在字符流缓冲区内
字符流要工作，必须有编码支持——但这个环节由转换流承担：
-
InputStreamReader：把InputStream（字节流）解码为字符流，需显式指定Charset（如UTF_8） -
OutputStreamWriter：把字符流转为字节流写入，同样依赖Charset -
FileReader/FileWriter看似“无参”，实则隐式使用Charset.defaultCharset()（通常是系统默认编码，Windows 是 GBK，Linux/macOS 多为 UTF-8）
注意：一旦字符进入 BufferedReader 的 char[] 缓冲区，它就是纯 Unicode 字符（UTF-16 代码单元），后续所有 read()、skip()、mark() 操作都不再涉及编码。
立即学习“Java免费学习笔记（深入）”；
缓冲区大小不影响编码结果，但影响解码时机
缓冲区大小不改变“哪个字节对应哪个字符”，但它会影响解码行为的粒度：
- 小缓冲区（如 128 字符）可能导致多轮
read()调用，每次从底层InputStreamReader拿一批字符——而InputStreamReader内部也有自己的字节缓冲（通常 8192 字节），它按需解码字节块 - 遇到多字节字符（如 UTF-8 中的中文），只要字节未截断，
InputStreamReader就能正确还原为完整char或char[]（对代理对也做正确处理） - 缓冲区再大，也不会让“GBK 编码的文件用 UTF-8 解码”变得正确——编码错误在解码入口就已发生，缓冲只是搬运已解码的结果
实际写法中，缓冲与编码是分层组合的
典型安全写法体现分工：
// 正确：明确编码 + 显式缓冲
Reader reader = new BufferedReader(
new InputStreamReader(
new FileInputStream("data.txt"),
StandardCharsets.UTF_8
)
);
Writer writer = new BufferedWriter(
new OutputStreamWriter(
new FileOutputStream("out.txt"),
StandardCharsets.UTF_8
)
);
这里三层关系清晰：
- 最外层
BufferedReader/Writer：提速，操作字符 - 中间层
InputStreamReader/OutputStreamWriter：唯一负责编解码的组件 - 最内层
FileInputStream/FileOutputStream：只管读写字节，不识字符
漏掉中间层（比如直接用 FileReader），就等于把编码控制权交给系统默认值，跨环境极易乱码。
