C# .NET6下对比原文件与GZip归档时GZipStream读取字节数不足问题

首先明确一个核心契约：所有 .NET 中 Stream 派生类的 Read 方法，从来没有承诺过会一次性读满你传入的请求字节数。
根据官方定义，Read 方法的返回值规则是：

• 返回 0 代表当前流已经读取到末尾，没有更多数据
• 返回值大于 0、且小于你传入的请求读取长度，是完全合法的正常行为，只要返回的字节是当前流中可立即读取的有效数据即可

你在 .NET Core 3.1 下跑通逻辑，本质是依赖了当时 GZipStream 的未文档化实现细节——旧版本的 GZipStream 内部会凑满请求长度再返回。.NET 6 对 GZipStream 的底层解压逻辑做了全量重写，替换了原有的 zlib 封装层，优化了内存分配和吞吐量，新实现只要内部解压缓冲区有可用数据就会直接返回，不会等待凑满请求长度，所以才会出现单次返回几百字节的情况。这不是 .NET 6 的 bug，反而是你之前的代码本身不符合流操作的契约，之前能正常运行纯属巧合。
你自己实现的 ForceRead 循环读满缓冲区的逻辑不是临时补丁，是流读取场景下需要固定长度读取时的标准正确写法，不存在兼容性问题。

相比逐字节逐块直接比对，基于增量哈希的校验方案性能更高、出错概率更低，具体实现逻辑如下：

• 块大小选择 16KB 即可，这个数值是文件系统预读、GZip解压、CPU哈希计算的综合最优值，比4KB的IO次数更少，比64KB的内存占用更低
• 初始化两个增量哈希实例，推荐用 SHA256.Create()，不建议用MD5、SHA1，存在哈希碰撞风险会导致校验误判
• 打开原文件流的时候指定 FileOptions.SequentialScan，提示操作系统做顺序读预读，降低磁盘IO等待延迟；初始化GZipStream时指定 leaveOpen: false，自动释放底层资源避免泄漏
• 用你写的ForceRead方法逐次从两个流读取对齐长度的块，每读到一块就分别喂给两个哈希实例做增量计算；如果读取过程中两个流的实际读取长度不一致，直接判定为内容不匹配，立刻终止校验不用读完整个文件
• 两个流都读完后，对比两个哈希实例输出的哈希值，完全一致则代表原文件和GZip压缩包内的文件内容完全匹配
  现代CPU基本都内置SHA计算硬件指令，.NET会自动调用硬件加速，哈希计算的吞吐量远高于手动逐字节比对的逻辑，大文件场景下性能差距尤其明显。

如果不想用哈希，也可以做逐块比对优化：每读满一块对齐的缓冲区就立刻逐字节比对，一旦发现不一致直接返回不匹配，不用读取后续内容，遇到内容不匹配的大文件可以节省大量IO和计算时间。

public static int ForceRead(this Stream stream, Span<byte> buffer)
{
    if (stream == null) throw new ArgumentNullException(nameof(stream));
    int totalRead = 0;
    while (totalRead < buffer.Length)
    {
        int currentRead = stream.Read(buffer.Slice(totalRead));
        if (currentRead == 0) break; // 流已到达末尾
        totalRead += currentRead;
    }
    return totalRead;
}

注意：这个规则适用于所有Stream派生类，不止GZipStream，FileStream、NetworkStream、CryptoStream、SslStream等所有流的Read方法都遵循相同契约，任何依赖“Read返回值等于请求长度”的代码，在后续.NET版本更新、运行环境变化时都可能出现异常。

内容的提问来源于stack exchange，提问作者dafie