选字符流处理纯文本（如.txt、.json），因其自动处理编码且支持按行读取；选字节流处理二进制数据（如图片、pdf），因其不解析内容、避免损坏；不确定类型时默认用字节流。
选字节流还是字符流，关键看数据本质——是纯文本，还是二进制。
看数据类型：文本用字符流，其他一律用字节流
字符流专为文本设计，能自动处理编码转换（如 UTF-8、GBK），适合 .txt、.csv、.json、.xml、Java 源码等可读文本文件。它读出来就是 String 或 char，直接可做字符串操作。
字节流不关心内容含义，只管按 byte[] 读写，因此适用于图片、PDF、MP4、ZIP、class 文件、网络原始报文等一切二进制数据。哪怕你强行用字符流读一张 PNG，解码过程会把 3 字节的 UTF-8 汉字误拆、把非文本字节当非法字符丢弃或替换成 ，结果必然损坏。
- 文本文件（含带中文、emoji、多语言）→ 优先用 Reader/Writer 及其子类（如
BufferedReader） - 非文本文件 → 必须用 InputStream/OutputStream 及其子类（如
FileInputStream） - 不确定文件类型（比如用户上传的任意文件）→ 默认用字节流，安全且通用
看编码控制需求：字符流必须显式指定编码
FileReader 和 FileWriter 会偷偷用系统默认编码（Windows 常是 GBK，Linux/macOS 常是 UTF-8），一旦文件编码和系统默认不一致，立刻乱码。这不是 bug，是设计如此。
真正可控的做法是绕过 FileReader，改用 InputStreamReader + FileInputStream 组合，并明确传入 StandardCharsets.UTF_8 等标准编码：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
new InputStreamReader(new FileInputStream("data.txt"), StandardCharsets.UTF_8)
✘ 危险（依赖系统）：
new FileReader("data.txt")
看操作粒度：按行/按词处理选字符流，按块/按结构处理选字节流
字符流天然支持语义化读取：比如 BufferedReader.readLine() 一行一 String，Scanner.nextLine() 配合正则切分；适合日志分析、配置解析、CSV 行处理。
字节流更适合底层控制：比如跳过文件头 16 字节再读正文、按固定长度（如 512 字节扇区）读磁盘镜像、解析自定义二进制协议包头+包体。它的 read(byte[], off, len) 方法让你精确掌控每次搬运多少字节。
- 需要 按行、按字段、含中文文本处理 → 字符流 + 缓冲（
BufferedReader） - 需要 跳过头部、校验 CRC、拼接原始报文、兼容旧协议 → 字节流 + 缓冲（
BufferedInputStream）
性能与缓冲：两类流都该加缓冲，但方式不同
不加缓冲的流（如裸 FileInputStream 或 FileReader）每 read 一次就触发一次系统调用，I/O 效率极低。实际项目中，99% 的场景都要套一层缓冲流：
- 字节流：用
BufferedInputStream/BufferedOutputStream - 字符流：用
BufferedReader/BufferedWriter
注意：BufferedReader 的 readLine() 内部已优化换行识别逻辑，比手动用字节流读完再 new String() 更简洁可靠；而字节流缓冲后，仍需你自己判断何时构成完整消息（比如遇到 \n 或特定结束标记）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
