inputstreamreader 不提供手动暂存字节机制，其内部由 streamdecoder 自动缓存不完整多字节字符（如 utf-8 中缺失尾字节），待后续输入补全后解码，开发者无法访问该缓冲区。
InputStreamReader 本身不提供手动暂存字节的机制——它内部由 StreamDecoder 管理字节缓冲与解码逻辑，对用户透明。当底层 InputStream 返回不完整的多字节字符（如 UTF-8 中只剩前 2 字节的三字节字符），InputStreamReader 会将这些“残缺字节”保留在其内部缓冲区中，等待后续输入补全，而不是丢弃或报错。
内部缓冲机制自动处理不完整字符
Java 的 InputStreamReader（通过 StreamDecoder）在解码时遵循标准字符集规范：
- UTF-8 解码器识别字节模式：0xxxxxxx（单字节）、110xxxxx + 10xxxxxx（双字节）、1110xxxx + 10xxxxxx + 10xxxxxx（三字节）等；
- 若读到
1110xxxx开头但后续不足两个10xxxxxx字节，剩余字节会被暂存在解码器的私有 byte[] 缓冲区中； - 下次调用
read()或read(char[])时，先尝试用新读入的字节补全，再输出对应字符； - 这个过程完全自动，开发者无需干预，也**无法直接访问或操作该内部缓冲区**。
不能手动暂存，但可控制输入节奏
如果你需要显式控制字节暂存（例如实现自定义粘包解析、网络流边界处理），不应依赖 InputStreamReader，而应：
- 用
InputStream读取原始字节，自己维护 byte[] 缓冲区； - 使用
java.nio.charset.CharsetDecoder手动解码：调用decoder.decode(ByteBuffer, CharBuffer, boolean endOfInput)，其中endOfInput=false允许保留未完成的字节序列； - 示例场景：从 SocketChannel 分批读取，每次 decode 前设置
ByteBuffer的 limit，并传false表示数据未结束，解码器会将未完成的字节留在 input buffer 中供下次使用。
避免乱码的关键是保证输入完整性
实际开发中，“读取不完整多字节字符”通常不是 bug，而是正常现象，只要：
- 底层流最终能提供完整字节（如文件读完、Socket 正确关闭、HTTP body 完整接收）；
- 不要在解码中途强行关闭
InputStreamReader或截断流； - 不要用
InputStreamReader.read()单字节读取大文本——效率低且易受缓冲影响；推荐用char[] buf批量读取。
调试时如何确认内部暂存行为
虽不能直接查看内部缓冲，可通过以下方式间接验证：
- 构造人工测试：用
ByteArrayInputStream提供不完整 UTF-8 字节序列（如{(byte)0xE4, (byte)0xB8}），然后调用InputStreamReader.read()——首次返回 -1（无完整字符），内部缓存这 2 字节；再用另一个含后续字节（如{(byte)0xAD}）的流接续，或重置流并补全，即可读出“中”； - 注意：跨流复用
InputStreamReader不可行，必须新建实例；内部缓冲属于单个解码器生命周期。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
