状态：本篇整体为建议，可调整；所承接的「结果未知不当作失败、部分成功保留逐项结果、不能安全重试的动作不自动执行」等原则已确认。故障注入验收、四端生命周期与服务端幂等验证均未执行，目标产品的恢复验证也未执行。 更新：2026-10-19 所属章节：系统状态、权限与恢复
本页承接已确认的「结果未知不当作失败、部分成功保留逐项结果、不能安全重试的动作不自动执行」等原则。具体任务服务、幂等保证、取消与恢复能力由产品及执行系统提供；本页不承诺所有动作都可恢复。
1. 先区分请求与业务结果
界面发出请求后，可能只知道通信是否完成，并不知道业务动作是否执行。请求被接受不等于任务完成；响应丢失也不等于任务失败。
建议为每个重要动作明确：
- 本次逻辑动作及对象范围。
- 请求是否被可靠接收，是否有可查询的任务或动作标识。
- 哪些状态是处理中，哪些是最终结果。
- 哪些证据足以认定成功、明确失败或部分成功。
- 结果不明时如何核查，哪些条件允许重试。
- 关闭页面、断网、取消与恢复会产生什么实际影响。
这些信息是实现契约，不要求对用户暴露内部协议，但用户可见状态必须有可信依据。
2. 执行状态与转换
| 当前状态 | 发生的事实 | 下一状态与用户反馈 |
|---|---|---|
| 尚未执行 | 用户明确发起有效动作 | 请求中；说明作用范围并防止重复触发 |
| 请求中 | 系统确认接收并继续执行 | 处理中；提供真实状态入口 |
| 请求中／处理中 | 单项动作已确认成功，或批次已结束且全部项核实成功 | 成功；说明实际完成内容 |
| 请求中／处理中 | 一部分项已完成，但仍有项目执行中 | 处理中；显示已完成进展及逐项状态，不提前给批次终态 |
| 请求中／处理中 | 批次已确认结束，成功与未成功范围均已确认 | 按实际结果汇总成功、部分成功或失败；保留逐项状态 |
| 请求中／处理中 | 批次执行已结束，但仍有项目结果尚未核实 | 说明执行已结束及已知结果，未核实项单列待确认；不声称完整终态 |
| 请求中／处理中 | 已确认未完成且不会继续执行 | 明确失败；保留工作，说明可行后续 |
| 请求中／处理中 | 连接中断或无法判断是否执行 | 结果待确认；核查同一动作，不盲目重试 |
| 结果待确认 | 查到仍在执行 | 处理中；继续查阅状态 |
| 结果待确认 | 查到完整且可信的最终结果 | 显示真实成功、部分成功或失败；否则继续保留待确认项 |
| 任一进行状态 | 用户请求取消 | 取消请求中；等待真实取消结果 |
服务器暂时查不到记录，也不必然证明请求从未执行；能否据此认定失败取决于执行系统的可靠保证。无法核实应继续诚实说明限制，而不是凭等待时长变成“失败”。
3. 长任务进度与离开行为
长任务应说明正在做什么、目标范围、已知进展以及离开页面后的行为。可显示阶段、已处理数量或逐项结果；只有可靠总量和计算依据时才显示百分比或预计剩余时间。
若任务可以后台继续，应提供可再次打开的状态入口，并区分“关闭查看”和“取消执行”。若离开会中断执行或无法恢复，应在离开前说明实际限制。没有跨会话恢复能力时，不显示暗示可永久追踪的文案。
根据任务影响范围决定用户可继续哪些工作；不应仅因有后台任务就冻结整个应用。与同一对象冲突的操作应限制或提示，非冲突阅读可继续。
3.1 跨组织切换后的任务归属
已提交任务绑定发起时的实际安全范围、对象集合、版本／快照语义、动作与操作者上下文。用户切换到另一组织或工作区只改变查看位置，不迁移任务，不自动取消或扩大它的范围，也不让后续重试改投新范围。取消、继续与重试分别遵守真实执行协议和当前授权。
原范围的进度或写入回执到达时，不写进新范围的列表、总数或操作反馈。产品若提供跨范围任务入口，应明确来源并在展示名称、数量和结果前检查当前披露权限；否则提供回到获准原范围的核查路径。权限撤回后不得继续泄露原范围内容，能显示何种最小状态由安全政策决定；不能把“目前无权查看结果”伪报成任务失败、已取消或从未发生。
4. 结果待确认的交互
例如“提交请求已发出，暂时无法确认结果。正在核查此次提交。”比“网络错误，请重新提交”更准确。后续可用动作应围绕核查原请求：刷新状态、查看任务结果，或产品实际支持的人工处理路径。
核查期间防止再次触发相同后果，保留必要的任务身份与输入。不能简单重新启用原按钮，让用户无法判断是否会重复执行。
如果最终无法确认，应说明哪些事实已知、哪些仍未知、用户可以采取什么获准措施。需要联系支持时可以提供可安全分享的参考标识，但不附上凭证或受限数据。不得声称一定能撤销或保证不会重复。
5. 重试与幂等边界
界面禁用按钮只能减少重复点击，不能保证不重复执行。安全重试依赖执行系统识别同一逻辑动作、验证输入与当前条件，并对重复请求给出一致处理。
建议实现契约明确：
- 同一逻辑动作的识别范围和有效条件。
- 重复请求是否返回已有结果，还是可能再次产生后果。
- 参数、对象或业务条件改变后，是否应作为新的动作重新核查与确认。
- 网络、应用重启或跨会话后，是否仍能关联原动作。
不在通用规范里规定具体幂等键格式、服务端存储期限或数据库策略。实现缺少可靠保证时，不应自动重发可能产生后果的写入。
读取重试、保存草稿重试和正式业务提交重试应分别评估。自动重试必须有限制和可观察结果，避免持续给用户或系统造成负担；具体节奏由实现按服务能力确定。高后果动作或结果未知动作不能仅以“改善体验”为由自动再执行。
用户修改了输入再提交，应明确这是新的意图，并重新校验范围与后果，不能用旧动作结果冒充新动作成功。
6. 批次生命周期、部分成功与逐项恢复
批次生命周期与逐项结果是两个维度。仍有项目执行中时，批次保持“处理中”，可以显示“已完成 97 项”，不能提前显示批次部分成功。只有批次已确认结束，才按已核实的完整结果汇总成功、部分成功或失败；若执行已结束但仍有未核实项，应明确“执行已结束，部分结果待确认”，不把未知项补成失败。
部分成功需要保留批次与项目之间的关系。每项至少能区分已成功、明确失败、未执行、仍处理中或结果待确认；不能把所有未成功项统一归入失败重试。
结果页应同时说明批次是否仍在运行、已核实的成功数量、未成功范围及各类原因。数量未知时使用真实描述，不伪造精确汇总。用户可按任务需要查看、筛选或导出获准的结果明细。
重试前：
- 排除已成功项，避免重复处理。
- 对结果待确认项先核查。
- 对明确失败项说明需修正的内容，并重新核验当前权限和业务条件。
- 说明此次重试的实际范围与是否可能产生新的后果。
- 将重试结果与原批次关联，避免同一记录在多个结果页里难以追踪。
部分成功不自动意味着系统能回滚成功部分。只有产品提供补偿、撤销或回滚能力时，才显示相应操作，并说明范围、条件及可能失败的后果。
7. 取消、停止与撤销
- 取消请求表示用户要求停止；尚未确认，不代表执行已经停止。
- 已取消表示系统确认按定义停止。已经完成的部分是否仍生效，应另行说明。
- 关闭页面通常仅改变查看位置，不应默认取消后台任务。
- 撤销或补偿是对已生效结果的新动作，不等于停止原请求。
取消与成功可能同时发生竞争。最终界面应采用可信的业务结果：若已完成，显示实际完成而不是停留在“已取消”；若仅停止剩余项，明确已完成与已停止范围。
撤销入口只有在产品支持且当前条件满足时提供；期限、约束与后果取真实规则，不添加任意承诺。
8. 乐观反馈与可靠确认
低风险、可恢复且服务端行为明确的操作可以考虑乐观反馈，但应保留“等待确认”的语义及失败回退路径。不能因为界面先显示变化，就把业务记录视为已经正式生效。
涉及不可逆后果、外部动作、审批、权限变化或难以补偿的工作，通常应等待可靠结果再宣布完成。是否采用乐观模式由产品风险及实现能力验证决定，不作为所有组件的默认优化。
回退时要保留用户后续修改，不能用旧快照覆盖新的意图。响应乱序时，只更新对应动作或数据基准，不让晚到结果取代更近的有效状态。
9. 恢复能力说明
恢复应按实际支持场景声明：同页面、页面往返、刷新、应用重启、重新登录、跨设备、离线后重连等。每种情况说明能恢复什么、依赖什么权限与存储、哪些结果仍需核查。
恢复任务时先核查当前权限、对象和任务状态，再恢复允许保留的输入与结果。原任务已结束时，不从旧草稿重新执行；数据改变时重新核查，详见 对象、任务与流程的衔接。
10. 故障注入验收（全部未执行）
- 服务端已成功但响应丢失：界面进入结果待确认，核查后显示成功，不产生第二次后果。
- 请求在接收前明确失败：保留输入；仅在已知安全条件下允许重新发起。
- 用户连续点击或按快捷键：同一动作不会因多个入口而重复执行；后端保证需有证据。
- 批次中成功、失败与未知并存：分类准确，重试不包含成功或尚未核实的项；仍有执行中项时保持处理中，执行结束但结果未完整核实时继续显示待确认范围。
- 取消请求到达时任务刚完成：最终状态采用真实结果，不虚报取消。
- 任务在后台继续，用户离开并返回：在支持范围内找到同一任务及当前结果，不创建新任务。
- 旧响应晚于新动作返回：不会覆盖新状态或把新输入标为已提交。
- 网络恢复：安全读取可恢复；高后果或结果未知写入不会未经核查自动重发。
- 无恢复能力或查询失败：界面如实说明限制和真实下一步，不编造完成时间与撤销能力。
11. 恢复场景与安全重试夹具
规则 YUDS-120100-01（恢复边界）
逐项声明返回页面、旋转／窗口尺寸变化、进入后台再前台、系统回收进程、用户主动退出、登出／换账号的恢复能力。页面位置、允许保存的草稿和执行任务身份分别记录，不以恢复导航树重放业务事务。系统状态恢复不等于持久草稿保存，也不构成业务动作成功证据。
| 场景 | 恢复前检查与可用预期 | 不得承诺 |
|---|---|---|
| 返回、旋转、窗口变化 | 保留仍有效对象和输入；重查权限、任务与基准，焦点按新布局定位 | 所有临时控件状态永远原样恢复 |
| 后台再前台 | 核查任务与数据变化，恢复获准工作；未知写入查询原动作 | 再次展示即自动提交或重新确认成功 |
| 系统回收进程 | 只从实际保存的最小定位信息、草稿存储和任务服务恢复；缺失时明确说明 | 仅内存状态足以恢复全部草稿 |
| 主动退出 | 依产品和平台实际保留策略恢复；可重查已发任务 | 关闭应用必定取消执行或必定保存最新输入 |
| 登出、换账号 | 隔离旧账号草稿、缓存与任务；新账号重新授权 | 旧页面恢复自动继承权限或重发旧动作 |
Apple 的 SceneStorage 是场景恢复机制，官方不保证持久化的时机与频率，也明确不用于敏感数据；Android 的 ViewModel 本身不能跨系统进程死亡保存，saved state 只适合轻量恢复信息。来源：Apple SceneStorage、Android Save UI states。这些事实仅证明不能用导航恢复代替业务存储，不要求采用特定 API。
HarmonyOS 恢复机制的现行官方事实与版本／设备限制统一见 平台适配、国际化与输入能力 第 11 节 P07 及 H-R2-03 来源，失败夹具见 端到端任务旅程与验收案例 G14。2026-10-19 曾从原官方恢复入口未取得正文，同日已读取官方现行文档及 API 正文，因此不能再把那次未取得正文当作当前未核实。目标产品的 SDK 绑定、可用设备和实际恢复验证仍未执行。
规则 YUDS-120100-02（重试与取消）
同一动作的范围、参数或业务条件变化后不得直接沿用旧成功结果；安全重试需当前权限、基准与执行系统可靠保证。查询“暂未找到”不足以认定未执行。取消请求和真实终态竞争时按实际结果归档，已完成项不得因取消动画变回未执行。各批次对账详见 查询、选择范围与批量执行 的 YUDS-090300-02。
夹具
| 规则 | 输入与动作 | 可验预期 | 反例 |
|---|---|---|---|
| YUDS-120100-01 | T 写入已发，系统回收进程；重新打开可恢复任务入口 | 先认证授权再查同一 T；已完成显示真实结果，未知继续核查，无第二次执行 | 还原“提交按钮已按下”并重放事务 |
| YUDS-120100-01 | 有敏感草稿时登出换账号 | 旧范围不可披露，按安全政策处理草稿；新账号不读取旧缓存 | 使用系统 UI 存储承诺敏感草稿完整恢复 |
| YUDS-120100-02 | 写入超时、首次查不到 T，用户重试；随后查到已完成 | 首次保持待确认，安全核查后展示完成，不重复后果 | 404 或等待超时自动变失败并重发 |
| YUDS-120100-02 | 取消请求发出前 A/B 已成功，C 在途最终成功，D 确认停止 | 最终保留 A/B/C 成功和 D 已取消／未执行的实际分类，说明只停止剩余范围 | 将 4 项全部显示已取消，或承诺自动回滚 |
上述协议由业务执行系统提供；YUDS 不指定键格式、保存期限或数据库事务。四端生命周期、故障注入及服务端幂等验证均未执行。
离线能力与同步状态的主合同见 系统状态、权限与恢复 的 PAT-OFFLINE；本篇继续持有未知结果、任务身份与安全重试规则，不由重新联网授权重发。
相关：权限与冲突见 权限变化、并发修改与保存冲突；表单提交见 表单校验、草稿与提交。