InputStream 的 readNBytes(int len) 方法，从方法名上看似乎是要“读满 len 个字节”，但实际行为却有些微妙——它最多读取 len 字节，如果读不够就返回实际读取到的字节数，不会自动补零，不会阻塞等待，也不会因为读不满而抛出异常。换句话说，这是一个“尽力而为”的读取工具，适用于大多数对精确字节数要求不高的场景。但如果你需要严格读满指定长度，就必须自己编写工具方法了。
先理清它的核心行为：
- 如果底层输入流中还有 ≥len 字节可供读取，那么好，返回一个长度为 len 的 byte[] 数组。
- 如果剩余数据不足 len 字节，比如只剩 3 字节，而 len=10，那就返回长度为 3 的 byte[]——不会自动补上 7 个零字节。
- 如果当前已经到达流末尾（available() 为 0 且没有更多数据），直接返回空数组
new byte[0]。 - 只有真正的 I/O 错误（例如 socket 中断、文件损坏）才会抛出 IOException；读不满这件事本身并不会触发异常。
简单来说，这个方法的设计初衷就是让你能安全、简洁地读取一段数据，无需手动编写循环和异常处理。但它并不适用于必须严格读满的协议场景——比如 TCP 的固定 8 字节头部、AES-CBC 解密块、文件格式校验字段，这些地方差一个字节都不行。
需要“严格读满 len 字节”时怎么办
如果业务逻辑要求必须获取 exactly len 字节，那就不能依赖 readNBytes(len) 了，需要自己封装一个阻塞式读取工具：
public static byte[] readFully(InputStream in, int len) throws IOException {
byte[] buf = new byte[len];
int total = 0;
while (total < len) {
int n = in.read(buf, total, len - total);
if (n == -1) {
throw new EOFException("Unexpected end of stream: expected " + len + " bytes, got " + total);
}
total += n;
}
return buf;
}
这个 readFully 方法会持续调用 read(byte[], off, len)，直到填满整个数组，或者遇到真实的 EOF 时抛出 EOFException。这才是“读不满就等到死”的可靠做法。
常见误区与替代选择
- 别用 readNBytes 配合 while 循环拼接：它本意就是单次读取一段数据，反复调用反而可能导致数据跳过或逻辑混乱。
- 不要假设 readNBytes(len) 总是返回长度为 len 的数组：尤其是在网络流（SocketInputStream）、压缩流或管道流中，提前截断是非常常见的现象。
- BufferedInputStream 不会改变 readNBytes 的语义：它只是优化性能，不影响“读不满即返回”的行为。
- 如果已知数据总长度且可预测，可以先用
readAllBytes()再切片，但要注意内存开销。
简单判断是否适合用 readNBytes
适合场景：
- 读取一个“尽力而为”的快照，比如日志片段、临时缓存。
- 解析变长但有长度前缀的结构：先读 4 字节长度，再用
readNBytes(长度)读取剩余内容。 - 单元测试中模拟小段输入，逻辑不依赖严格字节数。
不适合场景：
- TCP 协议中固定 8 字节的 header 必须完整读取。
- AES-CBC 解密要求块大小严格对齐。
- 文件格式校验需要逐字段比对长度。
