如何在.NET Core Azure架构下高性能构建并返回大型zip文件

推荐根据压缩包预估大小选择两种实现路径：

方案1：实时流式打包（适用总大小<10GB、文件数<1000的场景） #

全程无全量数据落内存/磁盘，边拉取边压缩边返回，用户等待时间最短：

• Service层直接调用Azure Blob SDK的OpenReadAsync()方法获取单个Blob的只读流，不需要下载完整文件到本地
• 使用System.IO.Compression.ZipArchive创建压缩包，模式设为Create、LeaveOpen = true，每拿到一个Blob流就新建一个Zip条目，把Blob流分段写入Zip流，写完立即释放当前Blob流
• API层直接将Zip流作为FileResult返回，设置响应头：Content-Disposition: attachment; filename=xxx.zip、Transfer-Encoding: chunked，不需要提前计算压缩包总大小
• 可控制并发预取3~5个小文件的流缓冲，平衡下载速度和内存占用，内存峰值可控制在200MB以内

方案2：异步预生成打包（适用总大小≥10GB、文件数过万的场景） #

解决Azure Function执行时长限制，稳定性最高：

• API层收到请求后生成唯一任务ID，将任务ID、过滤条件、文件列表存入持久化存储，直接返回任务ID给前端
• 后端用队列触发型Azure Function执行打包任务：边拉取Blob流边写入Blob存储中专门的结果容器的Zip文件，全程不占用Function本地存储和大量内存
• 打包完成后更新任务状态为已完成，绑定结果Zip的限时SAS链接（建议有效期24小时）
• 前端可通过任务ID轮询打包进度，完成后直接跳转SAS链接下载，结果文件可设置定时生命周期自动清理过期文件，节省存储成本

• 所有文件读写操作都用分段流处理，单段缓冲大小设置为4KB~8KB即可，禁止一次性加载完整Blob到内存
• 控制Blob拉取并发数为CPU核心数*2，避免打满存储账户带宽或占用过量Function连接数
• 消费计划的Azure Function最大执行时长为10分钟，超过该时长的打包任务必须用异步预生成方案
• 预生成的Zip文件天然支持断点续传，适合大体积压缩包的下载场景

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