· Zcode Team · 数据工程 · 约 3 分钟阅读
大数据量导出，为什么不该一直等一个请求？
拆解同步导出的超时风险，并说明异步任务在进度、结果和失败处理上需要怎样设计。
数据导出看似只是“查询并生成文件”，但数据量一大，请求会受到网关超时、数据库压力、内存占用与浏览器等待时间的共同限制。
同步导出的边界
少量数据直接返回文件通常简单有效。但如果先把全部记录加载进内存，再一次性生成文件，请求量和数据量同时增长时，内存与延迟都会变得不可预测。延长超时时间只能暂时掩盖问题。
设计前需要确认三件事：单次最大数据量、查询条件是否有索引、生成文件时能否分批读取和写入。只改前端加载动画，并不能降低后端处理压力。
异步任务的完整流程
用户点击导出后，服务端先创建任务并返回任务编号。后台按批次查询、生成文件、上传到受控存储。前端轮询任务状态，完成后获取下载地址。
这条链路至少应有 等待中 → 处理中 → 已完成 / 失败 几种状态。进度百分比要有明确含义；如果只能知道已处理记录数，可以显示“已处理 N 条”，避免任务到 100% 后还在上传文件，让用户误以为卡死。
结果一致性也要考虑
导出开始到结束期间，源数据可能改变。需要明确这是“开始时刻的快照”，还是“每批查询时的最新数据”。这个选择会影响分页方式与最终结果。
最后还要设置任务过期时间、下载权限校验、失败重试规则和存储清理策略。只有这些环节完整，异步导出才真正改善了用户体验。