真正掌握字符流解码的关键是理解reader通过streamdecoder和charset将字节转为字符，必须确保解码字符集与文件实际编码完全一致；filereader不可控编码，应改用inputstreamreader显式指定charset。
要真正掌握字符流的解码机制，关键不是背接口方法，而是看清 Reader 如何把字节变成字符——它本身不处理字节，真正干活的是它背后的 StreamDecoder 和所绑定的 Charset。编码集匹配不是“选对就行”，而是必须让解码用的字符集和文件实际存储的编码完全一致。
Reader 本质是“解码器+数据源”的组合
Reader 是抽象层，不直接读磁盘或网络。它依赖底层字节流（如 FileInputStream）提供原始字节，再由 InputStreamReader 中的 StreamDecoder 按指定 Charset 进行解码。FileReader 只是快捷写法，等价于：
new InputStreamReader(new FileInputStream(file), Charset.defaultCharset())- 它不暴露 Charset 参数，所以无法控制解码逻辑
- 所有字符识别、多字节汉字合并、BOM 跳过等动作，都由 StreamDecoder 在 read() 调用时动态完成
解码失败的典型表现与根因定位
乱码不是随机发生的，每种异常都有对应线索：
- 开头出现“”或“???”：文件带 UTF-8 BOM，但用 GBK 解码 → BOM 的 3 字节被当普通字符解析
- 中文变问号或方框：文件是 UTF-8，系统默认为 GBK，且未显式指定 charset → 解码时字节序列无法映射到有效 Unicode 码位
- 读取一半卡住或抛 MalformedInputException：UTF-8 文件中存在非法字节序列（如截断的 3 字节汉字），而解码器严格校验
- 英文正常、中文乱码但长度不变：说明按单字节读了（如误用 InputStream），而非按字符单位解码
实战中确保编码匹配的四步操作
不靠猜测，靠验证和显式声明：
- 查源文件真实编码：用编辑器（如 VS Code 底部右下角）或命令行
file -i filename（Linux/macOS）、PowerShell Get-Content -Encoding UTF8（Windows）确认 - 运行时打印系统默认编码：
System.out.println(Charset.defaultCharset().name());，避免假设 - 弃用 FileReader，改用 InputStreamReader + 显式 charset 名称：
new InputStreamReader(new FileInputStream("a.txt"), "UTF-8") - 写入时也同步指定：OutputStreamWriter 同样需传入相同 charset，保证“怎么写进去，就怎么读出来”
BufferedReader 不改变解码逻辑，只优化读取效率
BufferedReader 是装饰器，它缓存的是已解码后的 char[]，不是原始字节。所以：
-
new BufferedReader(new FileReader(...))仍走系统默认编码，乱码照旧 - 正确写法是：
new BufferedReader(new InputStreamReader(new FileInputStream(...), "UTF-8")) - readLine() 返回的 String 已完成解码，内部不再涉及字节处理
