D1.11.4In-progress state设计研究
长耗时任务需要在两种反馈之间提供过渡状态
别名: pending state · processing state · task transition · asynchronous progress
概念解释
进行中状态（in-progress state）是在输入已被接收、最终结果尚未产生之间，向用户说明任务仍在执行、目前处于何处以及可以采取什么行动的反馈。它不是简单的加载动画，而是异步工作真实生命周期的一段可见表示。上传、生成、审核、付款、导入和同步若只从「收到」跳到「完成」，中间的等待会成为黑箱；进行中状态把黑箱变成可追踪的过程。
机制
长等待会持续产生新的问题：工作是否还活着、能否离开、是否可取消、失败会在哪里出现、完成后如何继续。接收确认只能回答第一个瞬间，完成反馈只能回答最后结果，无法支撑等待期间的决策。进行中状态通过进度、阶段、队列、预计范围、后台策略或取消入口维持可预测性，也避免用户把静默误读为失败后重复提交。它应随真实过程更新，而不是用循环动画掩盖未知或停滞。
怎么研究
在不同任务长度、网络条件、后台切换、取消、重试和失败注入下，比较只有起止反馈与包含进行中状态的版本。测量用户是否重复操作、能否准确判断任务仍在执行、何时选择离开或取消、以及任务恢复后的定位能力。研究要覆盖长尾等待和状态异常：顺利快速完成的样本不足以检验中间状态，因为用户尚未来得及依赖它。
边界
短到不值得中断注意的任务不应强制显出复杂过程；瞬间闪过的多层状态只会制造闪烁。未知总量也不必伪造百分比，可用阶段、活动证据或可追踪队列说明。相反，进行中状态不能无限延长：真正失败、权限被拒、网络失联或任务被暂停时，必须转换为相应的明确状态并给出恢复路径。显示「处理中」不是延迟报告错误的许可。
怎么落地
- 为每类长任务定义从接收、进行、完成、失败、取消到重试的状态机，并明确每次转换的真实事件来源。
- 在进行中阶段提供与任务长度相称的信息：短等待可显示活动证据，长等待增加阶段、剩余范围、后台继续和取消后果。
- 允许用户离开时保留任务可追踪入口和完成通知；不允许离开时说明限制及替代操作，避免静默锁住界面。
- 在断网、后台恢复、服务器长尾和取消中演练，要求用户说出任务现在在哪里、还能做什么、何时应寻求帮助。