Java InputStream readNBytes 固定长度读取字节数组

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 解密要求块大小严格对齐。
• 文件格式校验需要逐字段比对长度。