本质区别在于：inputstream操作字节（8位），reader操作字符（16位）。前者读原始字节，不涉编码；后者必须解码，依赖charset；二者适用对象不同，需通过inputstreamreader桥接协作。
本质底层界限就一条：InputStream操作的是原始字节（8位 byte），Reader操作的是解码后的字符（16位 char）。这不是命名习惯或用法差异，而是数据单元、编码责任和设计目的的根本分叉。
数据单位不同：字节是物理存储单位，字符是逻辑语义单位
InputStream每次调用 read() 返回一个 0–255 范围的 int 值，它只代表一个原始字节，不解释含义。比如汉字“你”在 UTF-8 中占 3 个字节，在 GBK 中占 2 个字节——InputStream 会分三次或两次读出，每次都是独立字节，无法自动拼成“你”。
Reader 的 read() 每次返回一个 0–65535 范围的 int，对应 Java 内部的一个完整 Unicode 字符。它必须从底层字节中识别出编码边界，把多个字节“组装”成一个字符。这个动作不是可选的，而是 Reader 类型存在的前提。
编码责任归属不同：谁管解码，谁就承担乱码风险
InputStream 完全不管编码——它把文件内容当“黑盒字节流”，读出来是什么就是什么。你用它读中文文本，得到乱码不是它错了，而是你没做解码。
Reader 必须完成解码，否则无法输出字符。但 Reader 本身不持有编码规则，它的实现类（如 InputStreamReader）必须明确指定 Charset（如 UTF-8）。
常见误区：FileReader 看似简单，实则隐式使用系统默认编码（如 Windows 上常为 GBK），一旦文件是 UTF-8 编码，就大概率乱码。所以生产环境应避免直接用 FileReader，改用 new InputStreamReader(new FileInputStream(...), StandardCharsets.UTF_8)。
适用对象天然隔离：二进制 vs 文本，不可混用
字节流能安全处理一切文件：图片、音频、ZIP 包、序列化对象、网络协议帧……这些根本没有“字符”概念，强行用 Reader 去读，要么报错，要么读出无效字符。
字符流专为人类可读文本设计：.txt、.java、.json、.xml 等。它提供 readLine()、read(char[]) 等以字符/行为单位的操作，还支持按编码写入（如 PrintWriter.println("你好") 自动转 UTF-8 字节再写出）。
反过来说，用 InputStream 读文本，你得自己做字节→字符串转换（new String(bytes, StandardCharsets.UTF_8)），且要小心缓冲区边界；用 Reader 读图片，你会看到一堆无法显示的“字符”，实际是错误解码的结果。
桥梁类 InputStreamReader 是关键转折点
InputStream 和 Reader 不是互斥替代关系，而是协作关系。InputStreamReader 就是那个“翻译官”：
• 它包装一个 InputStream（提供原始字节）
• 接收一个 Charset（提供解码规则）
• 输出一个 Reader（提供字符视图）
没有 InputStreamReader，字节流就无法自然升维到字符层面；没有底层 InputStream，Reader 也就失去了数据来源。这种桥接结构正是 Java IO 分层设计的体现——分离“数据获取”和“数据解释”两个职责。
