数据导出交互要先说明“导出哪些数据”，再说明“什么时候能拿到文件”。小范围且能及时完成的导出可以直接下载；生成时间不稳定、需要后台处理的导出，应创建可再次找到的任务，展示范围、状态和结果。用户关闭页面后还能取回文件，比一条持续转动的进度提示更重要。
设计这条流程时，可以在墨刀原型中搭建导出弹窗和任务列表，把选择范围、等待、下载与恢复连成一条路径。原型先确认业务约定，实际的数据快照、文件生成和权限校验由研发实现。
“导出全部”到底指什么
订单列表有240条筛选结果，当前页展示20条，用户勾选了8条。这时一个“导出全部”按钮至少有三种解释：当前页20条、筛选后的240条，或者系统里所有订单。设计稿如果没有区分，研发很容易按接口最方便的方式实现。
用动词加对象写选项，让用户在提交之前确认范围。下面的数量只用于说明交互规则，实际界面应显示当前结果。
| 导出范围 | 建议文案 | 必须明确的规则 |
|---|---|---|
| 手动勾选 | 导出已选的8条订单 | 跨页选择是否保留；已经失效的记录如何处理 |
| 本次查询 | 导出符合当前条件的240条订单 | 显示日期、状态等生效条件，不受当前分页限制 |
| 当前页 | 导出当前页20条订单 | 页码与排序是否影响输出，翻页后范围是否变化 |
只有一种合理范围时，不必强行增加选择框。例如月度对账页面可以直接写“导出9月对账单”，并在旁边显示账期与主体。范围多选项是为消除歧义，不能成为每次下载前的固定障碍。
“当前显示的列”也不一定等于“应该导出的字段”。列表可能为了易读隐藏订单地址，导出却因个人信息权限必须排除它。将字段方案写清，例如“对账字段：订单号、支付时间、实付金额”，不要用“全部字段”掩盖权限差异。列表结构本身可结合B端数据表格的字段与批量操作设计一并整理。
同一后台还需要导入数据时，可按数据导入的字段映射与错误修正设计上传、预览、校验与修正流程，并与导出规则保持一致。
先约定数据取自哪个时点
用户10:00提交导出，10:03文件生成。期间新增了两条订单，另有一条金额被修改。文件应该取哪个时点的数据？这不是提示语能单独解决的问题，却会直接影响文件能否用于对账。
对需要复核的业务，推荐优先讨论“按提交时的筛选条件和可支持的数据时点生成”。任务记录保留筛选条件、申请时间与实际数据口径；如果系统只能在开始执行时查询最新结果，应明确采用执行时点，并在文件内留下生成说明。不要写“与页面完全一致”，除非数据集合与数值确实采用了相同快照。
这里有两个容易混淆的层次：固定筛选条件，能避免用户提交后修改页面筛选影响旧任务；固定数据快照，才可能保证后来变动的记录不会改变文件。仅保存条件并不等于保存快照。设计交付时把两项分开，让研发说明能够支持哪一项。
需要后台任务时，让用户可以离开
不建议用一个未经验证的行数阈值决定同步还是异步。相同行数可能因字段计算、图片打包或权限处理产生不同耗时。先根据实际系统能力判断能否及时完成；长任务或耗时不确定的任务，采用任务中心、下载记录等稳定入口。
点击“创建导出任务”后，页面提示“订单导出任务已创建，可在导出记录查看”，同时给出入口。任务处理中，用户可以继续查订单。离开当前页不取消后台任务；若产品确实需要页面保持打开，就不能宣称已经转入后台处理。
任务列表至少显示名称、申请时间、范围摘要、状态和可执行动作。对于经常导出同一类文件的用户，再补申请人或条件详情，避免“订单导出.xlsx”重复十次却无法辨认。文件名可包含业务范围与日期，但不宜把完整手机号等敏感信息写进文件名。
用真实阶段表达等待，不编造百分比
| 阶段 | 用户看到什么 | 可执行动作 |
|---|---|---|
| 排队 | 等待处理，保留申请时间 | 查看范围；支持取消时提供取消 |
| 生成中 | 正在生成文件；有可靠计数才显示进度 | 继续其他工作，不反复创建相同任务 |
| 完成 | 文件名、大小、生成时间与可下载期限 | 下载 |
| 失败 | 明确失败原因，如条件范围过大或服务暂不可用 | 按原因修改范围，或重试同一任务 |
| 已取消 | 任务已停止，说明是否存在可用文件 | 重新创建 |
| 文件已过期 | 旧文件不再可取，任务条件仍可查看 | 重新生成，并告知新文件可能采用新数据时点 |
进度达到100%应代表文件可获取，而不只是数据库查询结束。查询完成后还要压缩或写入存储时，可以显示“正在打包文件”，不要让100%停在原地很久。无法估计完成时间时，提供可回访的任务状态，通常比虚构“还剩10秒”更可靠。
结果暂时查询不到也不等于失败。创建请求超时后，若任务可能已经建立，应先通过任务标识核对结果，再允许重复提交；界面可写“正在确认任务是否创建”。这与明确创建失败后的重试，是两条不同路径。
部分数据失败，要让文件和提示说同一件事
假设240条订单中有3条处理失败。团队先决定是否允许部分交付：对不能缺项的对账文件，可以整项失败并说明原因；允许部分结果的业务，则显示“已导出237条，3条未导出”，同时提供未导出记录及原因。不能标题写“导出成功”，文件却悄悄缺了几条。
如果提供重试，明确重试全部240条还是仅处理失败的3条。前者可能产生新的数据时点，后者可能需要将补充文件与原文件一起使用；两种结果都不能默认等同于一份完整的新文件。把这种差别放在结果区域，而不是只留在后台日志。
下载成功与生成成功也要分开。文件已生成，但用户网络中断，可以重新下载同一文件，不必重复跑一遍生成任务。浏览器是否完成保存属于下载链路，任务列表中的“已生成”不应冒充“用户已拿到”。
权限变化和链接过期，各有恢复路径
用户创建任务时拥有导出权限，第二天下载时权限可能已改变。因此生成文件与下载文件都需要相应的权限规则。任务页面应该解释“当前账号无权下载”，并给出申请或联系入口；不能把权限失效伪装成文件损坏。
还要区分“下载链接过期”和“文件已经清理”。前者若文件仍保留且权限允许，可以刷新下载地址；后者才需要重新生成。面向读者的操作分别是“重新获取下载链接”和“重新生成文件”，不要统一写成“重试”。
有关完成提醒出现在哪里，可参考Toast、横幅与通知中心的选择。导出任务本身仍应有固定记录，不能把一条会消失的通知作为唯一下载入口。
把导出评审变成一次可走通的任务
- 准备一张有筛选、有勾选的订单列表，分别演示导出已选项与全部筛选结果，观察评审者能否复述数量和范围。
- 创建任务后离开列表，再从导出记录找到它；任务名称和范围应与提交时一致。
- 演示生成中、部分失败、完成和过期四种结果，每种状态都能解释文件是否可用、下一步是什么。
- 关闭再打开下载窗口，确认可以下载同一文件；把“下载失败”与“重新生成”区分开。
- 改变下载权限，再尝试取文件，检查提示与访问控制约定是否一致。
在原型中把这些分支连通后，将数据时点、部分成功策略和下载期限写在对应页面旁。评审的核心不是导出按钮够不够显眼，而是用户最终拿到的文件，能否解释它包含什么、漏了什么，以及还能不能再次取得。
