区分字节流与字符流的关键在于“怎么解释读到的东西”：字节流以1字节为单位搬运原始数据，不关心含义；字符流以字符为单位，需明确编码规则将字节转为Unicode，否则导致乱码。
区分字节流与字符流的关键，不在于“能不能读”，而在于“怎么解释读到的东西”。边界是否清晰，取决于数据本质和编码意图——字节流只管搬运原始字节，字符流则必须知道用哪套规则把字节还原成字符。
看处理单位和底层目标
字节流以 1个字节（8位） 为基本操作单位，所有 FileInputStream、OutputStream 及其子类都按此逻辑工作。它不关心内容含义，只确保字节序列原样传递。比如读一张 PNG 图片，第1024个字节是 0xFF，它就照搬过去，不问这是像素值还是控制标记。
字符流以 1个字符（Java 中为 char，16位 Unicode 码元） 为单位，实际背后仍靠字节传输，但中间嵌入了编码转换层。FileReader、BufferedReader 等每次 read() 返回的是一个 Unicode 码点（int 值），不是原始字节。这意味着：它必须明确知道源数据用的是 UTF-8 还是 GBK，否则 0xE4 0xB8 0xAD 在 UTF-8 下是“中”，在 ISO-8859-1 下就是三个乱码字节。
看变量类型是否携带编码语义
如果变量本身是 byte[]、ByteBuffer 或 int（表示单字节），说明你正在与原始二进制打交道，应选字节流路径。例如处理音频采样数据、序列化对象字节数组、网络协议包头，这些场景下强行转字符流不仅无意义，还会因编码误判导致数据损坏。
如果变量是 String、char[]、StringBuilder 或直接参与文本拼接/正则匹配/中文分词，那就该走字符流。此时变量已隐含语义：它代表可读文本，需要统一按某字符集解码。比如从文件读出 String content = "你好"，这个字符串内部已是 UTF-16 表示，源头若用字节流读取却未指定 UTF-8 编码，就会得到错误的 char 序列。
看传输链路是否存在编码转换点
纯字节通路：FileInputStream → CipherInputStream → ByteArrayOutputStream —— 全程无字符介入，加密/压缩/校验都基于字节，无需指定 charset。
含编码通路：FileInputStream → InputStreamReader（指定 "UTF-8"） → BufferedReader → String —— InputStreamReader 是关键转换节点，它把字节流“注入”字符流语义。漏掉这一步或 charset 不匹配，边界就模糊了：你以为读到了“张”，实际可能是“寮”或一堆 。
常见错误模式：
- 用 FileWriter 写文本却没配 OutputStreamWriter 显式指定编码，依赖系统默认（Windows 是 GBK，Linux/macOS 多为 UTF-8），跨平台必乱码
- 用 BufferedReader 读网络响应流，但服务器返回 header 声明 Content-Type: text/plain; charset=GBK，客户端却用 UTF-8 解码
- 将 byte[] 转 String 时写 new String(bytes)，没传 charset 参数，触发平台默认编码，结果不稳定
最优传输逻辑选择口诀
二进制数据 → 字节流；文本内容 → 字符流；不确定来源 → 先查协议/头信息再定 charset；涉及中文等多语言 → 统一强制用 UTF-8 并显式声明。
例如日志写入：若日志内容含用户输入中文，用 PrintWriter(new FileWriter("log.txt", true), true) 不够稳妥；应改用 PrintWriter(new OutputStreamWriter(new FileOutputStream("log.txt", true), "UTF-8"), true)。前者依赖 FileWriter 默认编码，后者锁定 UTF-8，边界清晰，迁移安全。
