任务进度完成条件需要先定义，百分比才有可以解释的含义。进度条到了100%，可能只是全部对象已经尝试处理，后面还需保存、汇总或核对结果。若界面把这一刻写成“全部成功”，用户就会把仍未就绪的结果当成可用成果。
设计先问系统究竟在计量什么、哪些条件共同成立才算完成，再决定是否显示比例。明确的阶段与实际数量，可以比一个准确性不明的百分比更有用。不要把延长到99%的动画当作最后验证阶段，也不要让失败任务因为进度满格而看起来成功。
百分比的分母，必须是能够解释的范围
以一批记录处理为假设，分母可以是本次确认对象数量，分子可以是已尝试处理数量。但“已经处理”需继续说明包括成功、跳过和失败哪些结果。对象全部尝试过，证明遍历结束，不证明每个对象都达到目标状态。相关操作可参阅《数据导入功能怎么设计？模板、校验、进度和失败修复》。
如果任务范围在执行期间仍会变化，单一百分比可能不适用。实施与产品先确认是否固定范围、如何处理新增对象，再给准确展示。不能不断改变分母，却让用户以为进度遵循一个固定目标。
文件读取、记录转换、数据写入和最终验证，各自有不同计量单位。若只采用其中一项比例，需要注明它代表哪阶段；若计划合成整体比例，权重与含义要有真实依据，不由设计按视觉顺滑随意分配。
没有可靠计量时，采用阶段与实际已确认数量即可。比如说明正在读取、正在处理或正在核对结果，必要时显示可确认对象数。文案用用户任务语言，不把内部流水日志全部展示成进度，也不伪造精确剩余时间。
开始前给本次采用范围和任务身份，后续进度才能对应。如果用户同时有多个任务，百分比旁边应有足够识别信息，避免一个任务的迟到消息被当成另一个任务已经接近完成。
将对象处理结束，与结果可以使用分开
处理结束后，可能需要生成结果明细、检查写入状态或准备文件入口。这些步骤影响成果能否使用，应有准确状态。不能将它们隐藏在100%旁边的无限转圈里，让用户不知道究竟等待什么。
每个阶段的完成依据可以写清：读取阶段采用文件已确认，处理阶段对象均取得结果，写入阶段保存结果已核对，汇总阶段明细可用。具体阶段按真实流程选择，不要求所有任务都增加一样的步骤。
前一阶段结束，进入后一阶段时说明变化，并避免让比例含义突然改变。用户看到100%后又回到0%，可能以为重做全部；如果确实是新阶段的局部比例，就给明确阶段名称与总体状态，让两者可以理解。相关操作可参阅《组件状态为什么总在开发阶段补？按钮、输入框和卡片至少要把这些状态设计完整》。
结果已经就绪时，提供能够查看或使用的实际入口，再将整个任务标为相应完成结果。生成了一份文件但访问入口尚不可用，或写入了数据但结果无法查询，都需要按实际完成条件表达，不能只有一个绿色图标。
对于不需要额外验证的小任务，可以保持简洁。阶段拆分的目的不是增加界面复杂度，而是将真实存在、影响用户使用的条件说明。不存在的核对任务不应为了让流程看起来专业而加进进度。
最后核对阶段，说明检查什么与等待边界
最终验证应有任务对象。例如核对本批记录当前状态、确认输出文件可取回，或生成可定位失败项的结果明细。说明这项工作与用户目标的关系，用户就能理解为什么处理比例已满但还不能使用结果。
验证耗时无法估计时，保持阶段说明与真实状态，不显示没有依据的秒数。若系统有可靠的更新时间或已检查对象数，可以用于核对任务仍在推进；信息变化频率也要适当，不用毫无意义的文字跳动制造工作感。
长时间没有变化时，按实际系统能力提供状态查询、任务查看或联系路径。超时如何定义、是否继续后台处理，由实现确认。界面不能仅因等待较久就宣称失败，也不能让任务永久停留在“快好了”而没有继续办法。
验证失败时，保留已经完成的阶段及当前问题。失败可能发生在成果准备或读取环节，不能把前面确实完成的处理全部抹掉；同样不能因为处理已结束，就忽略最后一步失败仍写成全任务完成。
重复核对与重复执行业务动作应分开。如果只需要重查现有结果，优先提供核对路径，不把一个“重试”按钮直接绑定到整批重新写入。具体恢复粒度由系统支持决定，名称准确反映当前采用动作。
完成结果还要区分全部成功、部分完成与终止
全部对象都有处理结果，不代表全部成功。结果摘要应给成功、跳过、失败和未处理数量，按照任务规则定义是否属于整体成功、部分完成或失败。用户需要看到可解释的组成，而不是只看到一条满格进度。
有些任务允许独立对象部分成功，结果明细可以支持继续处理失败项；有些任务要求整体满足条件，不能把局部结果直接投入使用。策略由业务与实现决定，进度文案按采用策略表达，不用同一种“完成”覆盖相反含义。
取消或终止后，说明已经执行部分与停止范围。用户取消的是后续处理，还是能够撤销现有结果，必须明确。进度停在某个比例只说明没有继续推进，不能代替终止结果，也不自动表示已经恢复原状。
跳过也不是失败或成功写入的同义词。它可能因为对象已满足条件、规则不适用或本次选择不改变旧记录。把原因与身份放进明细，用户才能知道是否需要进一步处理；不能为了让成功率好看，将所有跳过项计入目标已完成。
终态应能在后续入口继续查到。用户离开任务页再返回，可以看到本次范围、结果及未完成项。完成通知只帮助找到结果，不应成为唯一证据；具体是否有任务中心按系统实际能力安排。
验收从成果倒推，而不是只观察进度动画
先写一句本任务真正完成的标准。例如，确认对象取得规定状态，结果明细可定位，输出文件可以取回并与采用范围对应。标准可核对之后，再检查进度阶段是否覆盖了达成标准的实际步骤。
准备正常任务、部分失败、全失败、处理结束后核对失败、范围为空、取消与离开再返回等构造样本。每条写清预计阶段和终态，不使用真实私有数据制造演示。核对动画以外的实际结果。
范围为空时，可能无需处理任何对象，但仍需要准确说明没有可执行项。不能用计算比例出错后显示永久加载，也不能写成“已经处理全部对象”让用户误以为有业务变化。具体任务是否结束，按空范围规则确认。
检查最后一步失败时，页面是否仍显示全部成功；处理比例满格时，能否知道当前仍在核对；部分结果存在时，是否能够对应到对象。实施检查事实，设计检查解释与继续路径，二者共同支持验收。
如果同一任务在列表、详情和通知中显示状态，核对这些入口采用同一个终态定义。详情写正在验证，列表却标完成，会让用户从不同入口得到相反结论。共用状态规则，具体视觉可以依位置简化。
保存任务身份、范围、阶段定义、终态标准与实际测试结果。完成标志是百分比含义可解释，阶段切换准确，100%不冒充全部成功，失败与取消有真实边界，成果能够被验证与使用。进度因此成为任务信息，而不是一段等候装饰。
常见问题
对象都处理过了，可以直接显示100%成功吗？
不可以把遍历结束等同于目标全部达成。可以说明处理阶段完成，再按成功失败及结果就绪条件确定终态，具体比例要注明采用含义。
没有可靠分母，还需要做百分比吗？
不一定。阶段名称、实际确认数量与任务状态可以更准确。没有依据的精确比例会让用户误判剩余工作，不应为了视觉效果强行添加。
最后一步很慢，可以让进度一直停在99%吗？
不宜无说明地使用这种方式。说明当前正在核对或准备什么结果，提供实际状态与可用路径，让用户理解等待，而不是用数字掩盖阶段。
部分失败还能把任务写成完成吗？
需要明确完成的是处理过程，并展示结果组成。整体成功、部分完成或失败由任务策略决定，不能只用一个完成标签隐藏未达成目标的对象。
用户取消任务后，已经写入的数据会自动撤销吗？
取决于真实取消与恢复能力。停止后续工作不等于撤销既有结果，界面说明作用范围，不能用进度停止暗示已经恢复原状。
链接复制成功
