为何ZipArchiveEntry.ReadAsync读取字节数远少于Read，致异步解压性能差？

同步方式解压400MB归档文件仅需数秒，代码实现如下：

private static async Task ExtractFilesAsync(this ZipArchive archive, string destination, IProgress<int> progress = null)
{
    await Task.Run(() =>
    {
        long bytesWritten = 0;
        long totalBytes = archive.GetUncompressedSize();
        int percent = 0;
        foreach (ZipArchiveEntry entry in archive.Entries)
        {
            if (!entry.IsDirectory())
            {
                string fullPath = Path.Combine(destination, entry.FullName);

                using (FileStream writeStream = File.OpenWrite(fullPath))
                {
                    using (Stream readStream = entry.Open())
                    {
                        int chunkSize = 1024;
                        byte[] buffer = new byte[chunkSize];

                        while (true)
                        {
                            int bytesRead = readStream.Read(buffer, 0, chunkSize);
                            if (bytesRead == 0)
                            {
                                break;
                            }
                            writeStream.Write(buffer, 0, bytesRead);
                            bytesWritten += bytesRead;
                            int newPercent = (int)(bytesWritten / (double)totalBytes * 100.0);
                            if (newPercent > percent)
                            {
                                percent = newPercent;
                                progress?.Report(percent);
                                Trace.WriteLine($"{percent}");
                            }
                        }
                    }
                }
            }
        }
    });
}

但改用Stream.Read/Write的异步版本时，解压耗时飙升至约一分钟：

private static async Task ExtractFilesAsync(this ZipArchive archive, string destination, IProgress<int> progress = null)
{
        long bytesWritten = 0;
        long totalBytes = archive.GetUncompressedSize();
        int percent = 0;
        foreach (ZipArchiveEntry entry in archive.Entries)
        {
            if (!entry.IsDirectory())
            {
                string fullPath = Path.Combine(destination, entry.FullName);

                using (FileStream writeStream = File.OpenWrite(fullPath))
                {
                    using (Stream readStream = entry.Open())
                    {
                        int chunkSize = 1024;
                        byte[] buffer = new byte[chunkSize];

                        while (true)
                        {
                            int bytesRead = await readStream.ReadAsync(buffer, 0, chunkSize);
                            if (bytesRead == 0)
                            {
                                break;
                            }
                            await writeStream.WriteAsync(buffer, 0, bytesRead);
                            bytesWritten += bytesRead;
                            int newPercent = (int)(bytesWritten / (double)totalBytes * 100.0);
                            if (newPercent > percent)
                            {
                                percent = newPercent;
                                progress?.Report(percent);
                                Trace.WriteLine($"{percent}");
                            }
                        }
                    }
                }
            }
        }

}

调整chunkSize至1MB后，Stream.ReadAsync每次仅读取约15KB，而Stream.Read能读取完整1MB，性能瓶颈的核心原因如下：

• 压缩流的内部缓冲区限制：ZipArchiveEntry.Open()返回的是DeflateStream（或GZipStream），这类压缩流的内部解压缓冲区默认只有约16KB。同步Read方法会一次性利用CPU完成足够的解压操作，直接填满你传入的1MB外部缓冲区；但异步ReadAsync为了避免长时间占用线程，每次只会解压并返回内部缓冲区大小的数据——哪怕你传入更大的外部缓冲区，也只能拿到约15KB的结果，导致需要多次异步调用才能完成大缓冲区的填充，开销剧增。
• 异步上下文切换的额外成本：异步版本中，每一次ReadAsync和WriteAsync都会触发线程上下文切换，而解压本身是CPU密集型操作，频繁的调度损耗会被放大。同步版本用Task.Run把整个逻辑放到线程池线程，全程用同步IO和同步解压，避免了频繁的上下文切换。
• 异步实现的场景适配问题：压缩流的异步逻辑更偏向小批量、低延迟的场景，对于解压大文件这种CPU+IO混合密集的操作，同步模式反而能更高效地利用CPU资源，减少调度层面的损耗。

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