必须用InputStream处理原始二进制数据，如图片、音频、ZIP、HTTP响应体等；用Reader仅限已知编码的文本，须通过InputStreamReader显式指定编码（如UTF-8），避免默认编码导致乱码。
什么时候必须用 InputStream？
当你处理的不是文本，而是原始二进制数据时，InputStream 是唯一选择。比如读取图片、音频、ZIP 文件、网络协议包（HTTP 响应体未解码前）、加密后的字节流等。
关键判断点：如果数据里可能包含 0x00～0xFF 任意字节，且你不能丢失或误解释其中任何一个字节，就必须用 InputStream。
-
InputStream.read()返回int（-1 表示 EOF，0～255 是实际字节值），不会做任何编码转换 - 直接包装成
BufferedInputStream或DataInputStream可高效读取结构化二进制数据 - 不要尝试用
InputStream读中文文本——它不理解字符边界，会把 UTF-8 多字节序列拆开，导致乱码
什么时候该用 Reader？
只在明确知道数据是文本，并且你知道它的字符编码时，才用 Reader 及其子类（如 InputStreamReader、BufferedReader）。
典型场景：读取配置文件（application.properties）、日志文本、JSON/XML 原文、用户提交的表单内容等。
立即学习“Java免费学习笔记（深入）”；
-
Reader.read()返回的是 Unicode 码点（int，范围 0～65535），已经按指定编码完成字节→字符转换 - 必须通过
InputStreamReader将InputStream转为Reader，且显式传入编码（如new InputStreamReader(in, "UTF-8")），否则依赖平台默认编码（Windows 是 GBK，Linux/macOS 通常是 UTF-8），极易出错 - 用
BufferedReader的readLine()比InputStream自己按\n/\r\n切分更可靠，它能正确处理不同换行符和编码边界
InputStreamReader 是桥，不是透明管道
InputStreamReader 不是“把字节流转成字符流就完事了”，它内部有解码缓冲区，行为受编码方式和输入节奏影响。
- 遇到不合法字节序列（如 UTF-8 中孤立的
0xC0），默认抛MalformedInputException；可设CodingErrorAction.REPLACE替换为 - 如果底层
InputStream分多次返回字节（如网络流中一个汉字的 UTF-8 三字节被拆成两次read()），InputStreamReader会缓存未完成的字节，等齐了再输出字符——你不需要自己处理“半截 UTF-8” - 但这也意味着：调用
reader.read()后，底层InputStream可能已多读了几字节（被缓存在解码器里），所以别在同一个InputStream上混用InputStream和Reader操作
常见错误与绕过陷阱的写法
最常踩的坑是忽略编码声明，或误以为 String.getBytes() 和构造 String(byte[]) 是对称操作。
// ❌ 错误：没指定编码，依赖系统默认 Reader reader = new InputStreamReader(inputStream); // ✅ 正确：显式声明 UTF-8（除非你确定要其他编码） Reader reader = new InputStreamReader(inputStream, StandardCharsets.UTF_8); // ❌ 错误：认为 getBytes() 默认编码 = 构造 String 的默认编码 byte[] bytes = str.getBytes(); // 实际用平台默认编码 String s = new String(bytes); // 也用平台默认编码 —— 看似能 round-trip，但跨环境就崩 // ✅ 安全写法：始终绑定编码 byte[] bytes = str.getBytes(StandardCharsets.UTF_8); String s = new String(bytes, StandardCharsets.UTF_8);
另一个隐形坑：用 Files.newInputStream() + InputStreamReader 读文件时，别忘了 Files.readAllBytes() 本质也是先读字节再转字符串——若文件超大，优先用带缓冲的 BufferedReader 流式处理，避免 OOM。
