.NET Core 使用SharpZipLib从内存流生成Zip包下载提示损坏求助

1 优先排查响应压缩中间件冲突 #

这是该场景下最高发的问题：如果你的项目启用了UseResponseCompression中间件，且配置的压缩MIME类型列表包含application/zip，中间件会对已经是压缩格式的Zip包二次执行Gzip/Brotli压缩，导致客户端拿到的是双层压缩的损坏文件。

• 验证方式：临时注释启动类中的app.UseResponseCompression()代码后重新测试，如果下载的Zip可以正常打开，即可定位问题。
• 修复方案：修改响应压缩配置，将application/zip从待压缩的MIME类型列表中移除。

2 检查SharpZipLib写入完整性 #

虽然本地保存文件正常，仍建议在关闭ZipOutputStream前显式调用Finish()方法，确保Zip文件的末尾目录信息完整写入流中，优化后的生成代码如下：

public byte[] ZipFiles(IEnumerable<FileContentResult> filesToZip)
{
    using var outputMemoryStream = new MemoryStream();
    using var zipStream = new ZipOutputStream(outputMemoryStream);
    zipStream.SetLevel(3);

    foreach (var fileToZip in filesToZip)
    {
        var zipEntry = new ZipEntry(fileToZip.FileDownloadName)
        {
            DateTime = DateTime.Now
        };
        zipStream.PutNextEntry(zipEntry);
        zipStream.Write(fileToZip.FileContents, 0, fileToZip.FileContents.Length);
        zipStream.CloseEntry();
    }

    // 显式完成Zip结构写入，避免末尾信息丢失
    zipStream.Finish();
    zipStream.IsStreamOwner = false;
    zipStream.Close();

    return outputMemoryStream.ToArray();
}

3 检查控制器返回逻辑 #

确保返回时没有额外修改字节数组，正确的返回示例代码如下：

public IActionResult DownloadZip()
{
    var files = // 你的待压缩文件集合
    var zipBytes = ZipFiles(files);
    // 显式指定ContentType和文件名，同时设置ContentLength避免截断
    return File(zipBytes, "application/zip", "download.zip");
}

4 排查前端下载逻辑 #

如果前端使用Ajax/axios等方式发起下载请求，必须指定响应类型为二进制模式：

• 以axios为例，需要添加配置responseType: 'arraybuffer'，如果使用默认的text/json类型，会强制对二进制内容做UTF-8转码，直接损坏文件。

5 验证响应头正确性 #

通过浏览器开发者工具的网络面板，查看下载接口的响应头：

• 确认Content-Type值为application/zip
• 确认Content-Length值和你生成的zipBytes.Length完全一致，如果长度偏小说明响应被中途截断。

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