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