design-responsive-interactions

# 流畅交互与后台处理设计 让用户持续完成自己的任务。同步、计算、保存、校验和恢复由软件承担；优先让这些工作无感完成。确实无法消除结果依赖时，才让用户看到必要的等待。 适用于游戏、桌面软件、移动应用和网页。不依赖特定引擎、服务器、项目或框架。只审查或修改当前授权范围；规范本身不授权交易、真实数据写入或产品规则变更。 ## 先确定用户能继续做什么 设计或审查一条交互链时，先确认用户动作、即时反馈、最终结果、后续动作依赖和失败后的恢复路径。把用户可操作状态与内部任务状态分开；不能把 `pending`、`saving` 或 `retrying` 直接映射成全局禁用。 按以下顺序选择处理方式，前一层可行时不升级到后一层： 1. **无感处理**：减少工作量，预取、缓存、增量计算、后台执行或分帧处理；让操作按正常节奏继续。 2. **非阻塞反馈**：确有必要告知时，在相关对象或页面显示轻量状态；保留浏览、移动、编辑及其他不依赖结果的操作。 3. **局部等待**：结果是下一步必需前提，且无法安全预计算、排队或解耦时，只限制真正依赖它的动作。 4. **整体等待**：只有整个当前体验确实无法继续时才使用整页加载或全局输入限制，并提供明确状态与恢复出口。 “现在代码是同步调用”“后端接口还没返回”“实现方便”都不能作为必须等待的理由。采用局部或整体等待前，说明缺少哪个必要结果、为何无法隐藏耗时、影响哪些操作、何时解除。说明留在设计或评审中，不让用户阅读内部实现。 演出、回合、暂停或明确的玩法与业务规则可以主动限制操作。限制范围和结束条件必须来自产品设计；技术等待不能伪装成演出，演出结束后不能因后台收尾继续锁住用户。 ## 客户端本地状态与云存储 当产品以客户端当前缓存承载本地业务状态、云端用于持久化时，按以下方式处理普通业务与保存。不要把每次缓存保存设计成需要交易确认或失败补偿的远端命令。 - **业务立即更新当前缓存**：动作通过本地业务校验后立即生效，后续操作基于更新后的状态继续。一般业务模块只更新缓存，并通过已有变更接口标记变化；`dirty` 与版本由现有数据或同步机制维护。业务模块不决定上传时机、不主动调用上传、不等待云回执。 - **运行中复用已加载数据**：普通业务操作使用已加载的缓存，不在每次动作后重新从云端读取并整体加载持久化数据来确认保存。初始化、切换身份或产品明确要求的恢复仍按各自合同加载；不能借这些入口用旧回读覆盖运行中较新的操作。 - **现有同步模块统一保存**：复用项目已有的同步所有者与队列，在后台尽可能将最新待同步数据写入数据库。可覆盖的状态更新按对象与版本合并；普通业务不另建上传队列、交易确认、资源预留或补偿状态机。 - **按实际提交版本确认**：同步模块记录本次提交的对象、会话、本地版本及所依据的云端权威版本。成功回执只确认实际提交的版本；提交后又发生修改时，保留较新的缓存与 `dirty`，不能因旧提交成功就把整个对象标为已保存。共享任务成功、零写入完成或其他字段保存成功，都不能证明本次目标字段已提交；排队合并后仍须核对实际发送的字段和值。独立业务只按其真实依赖的字段与提交版本确认，既不能借无关字段成功冒认成功，也不能因无关字段的新修改否认已确认的目标字段。 - **保存失败不回滚业务数据**：超时、失败或旧响应不能把运行中的业务状态还原成提交前快照、旧云端快照或旧字段值，也不能撤销后续用户操作。保留最新待同步状态，由既有同步队列退避重试或处理版本冲突；不要求用户重做已经生效的本地动作。 - **权威版本与身份隔离**：写入端按既有权威版本或顺序约束拒绝过期写入；客户端核对账号、对象、会话和提交版本。读取权威状态是为了识别冲突并按既有规则协调差异，不能直接覆盖仍有修改的当前缓存。旧请求不能跨对象或跨会话清除 `dirty`、替换当前状态或撤销新操作。 - **保存承诺真实**：本地生效与云端保存成功分别表示。需要跨退出保留的最新缓存与待同步信息，复用已有本地持久化机制；未满足持久化条件不能显示已保存，故障也不能静默丢弃最新数据。 社交等本身依赖远端实时交互的业务，以及独立云数据对象的专有持久化接口，可以按自身合同处理真实依赖、校验和副作用。调试工具、明确的临时存档操作等专用入口，可以按显式用途使用既有持久化接口。不能仅因普通业务最终需要云存储，或一次动作涉及多个对象，就把它改成例外。 用户明确执行撤销、取消或恢复历史版本，以及独立远端业务按产品合同拒绝或撤销操作，仍按各自语义处理；本节禁止的是存储故障或旧请求触发的数据回滚，不是一概禁止产品的撤销功能。 全项目排查时，在授权范围内移除用于上述保存回滚的业务逻辑，包括失败回填旧值、快照覆盖和借权威回读撤销后续操作；保留必要的版本校验与冲突处理。不另造一套确认或补偿流程替代回滚。 ## 连续操作与结果正确性 - **立即响应输入**：及时表现按下、选中、接收或可逆预览，保留用户当前页面、焦点、滚动位置和输入。不能因静默刷新抢焦点、重置选择或把用户送回起始页面。 - **按依赖协调**：无关对象独立处理；同一资源或对象需要顺序时，在后台排队、合并或预留。只有语义允许覆盖的状态更新才能合并；购买、领取等独立意图不能被吞并。 - **接受动作要有保障**：承诺已接收或已保存前，满足相应的可靠接收或持久化条件。需要跨退出恢复的任务保存必要记录；不能只改画面后丢失用户操作。 - **区分预览与完成**：本地预览、本地业务已生效与云端已保存是不同事实，普通缓存保存遵循上一节。独立远端扣费、发奖、交易、删除等不可逆动作以其权威结果为准，等待期间保持其他功能可用。 - **展示读取不夹带业务写入**：展示查询不能隐式补写业务字段、迁移数据或修改关系。展示加工结果不得混入业务待保存状态；普通缓存及其持久化可以保留，但不能替代写操作所需的权威校验。共享查询被写流程复用时，不得为展示改变其业务查询语义；需要不同缓存语义时另设展示入口。 - **防止重复和乱序**：对独立远端命令，由业务区分原意图的重试与新的独立意图。对会重试的命令保留稳定操作标识，并核对实际执行端的幂等、查询或对账保证；客户端标识和防连点本身不能保证只执行一次。未知结果先确认原操作，不能换标识盲目重发。普通缓存保存由统一同步模块按版本处理；所有写入端都需按既有版本或顺序约束防止旧请求覆盖新状态，只过滤晚到响应不能保护真实数据。 - **必要预留需要收尾**：产品合同要求的远端待确认操作占用材料、余额或对象时，由明确拥有者在成功后结算、明确失败后释放。结果未知时保留核对依据，不盲目释放造成重复消费；依赖它的新动作采用可恢复排队或真实的局部等待。不能因普通缓存尚未保存到云端而额外冻结资源。 - **取消含义真实**：关闭面板、停止等待、取消未提交任务与撤销已生效业务分别处理。不能显示“已取消”却继续产生未说明的副作用；已提交且无法撤销时继续确认原结果，并在合适入口提供状态。调用者等待超时不等于实际操作终结；界面的无效等待及时结束，实际操作仍需的顺序与数据保护由原拥有者保留至操作终态，并覆盖合并、排队失败及异常收尾，不能随等待者退出提前释放。 - **取消覆盖整条提交链**：预检查、二次确认和业务回调共享本次意图的生命周期。关闭或换代后，在每次等待结束及首次副作用发出前核对意图是否仍有效，不能只在最外层忽略旧结果。已发出的业务按原操作继续确认，不能据界面取消宣称撤回。 - **业务收尾不依赖页面存活**：已接受操作的结算、冷却和完成记录由业务拥有者按原意图完成，不能因为发起页面关闭而跳过。界面代次只控制结果呈现；若产品允许取消尚未完成的动作，取消时不得同时发布该动作的结果。 ## 资源/前置不足：引导补齐 - **不足时提供补齐路径**：任何道具、材料或前置条件不足时，必须通过 UI 引导玩家在几步内补齐。先研究现有功能如何处理同类情况，复用已有弹窗、获取途径和补齐流程，不新建界面。 - **集中展示缺项**：打开现有「缺少道具」弹窗，显示所缺道具的获取途径；多项同时不足时全部列出，并允许一次补齐。前置条件不足时提供现有的对应完成入口。 - **直达现成补齐窗口**：已有补齐或兑换窗口时直接打开，例如贝壳不足时打开钻石兑换；钻石不足时打开充值页。兑换后重新校验条件，满足时自动继续原操作，不要求玩家返回后重新点击。 - **不能只改提示文案**：原有「某某不足」等 toast 可以保留，但必须同时提供可执行的补齐引导，不能用改文案代替完整交互。 - **不足不执行，退出有收尾**：仍不足的原操作不扣资源、不判成功。补齐、取消或失败不阻断玩家的其他操作，流程结束不残留遮罩或输入锁；已取消或失效的原意图不自动继续。 ## 无感也包括运行流畅 异步接口不能证明界面不卡。沿输入到显示结果的链路检查主线程中的计算、序列化、解压、磁盘访问、资源加载、布局和批量刷新。 按实际瓶颈选择减少工作量、缓存、预加载、批处理、增量更新、分帧执行或后台工作。受线程约束的界面与引擎 API 仍在合法线程调用；不能为了后台化破坏线程安全。 后台工作需要并发、队列、内存和重试预算，为交互保留资源。连续输入时可取消已过时的查询或计算；不可取消的业务提交继续由业务拥有者跟踪。采用合并、丢弃或队列上限时，明确哪些意图已被接受，不能静默丢失已承诺的操作。 在目标设备和代表性数据规模下测量输入反馈延迟、长帧、内存与任务积压，按产品已有预算验收。没有预算时先测基线并给出本次目标，不编造适用于所有软件的固定阈值。 ## 确实需要等待时 - 说明正在处理的用户事项，例如“正在准备场景”“正在生成预览”；避免把内部同步、锁或存档校验问题抛给用户。 - 能继续的区域保持可操作。能在后台继续的任务允许离开当前界面，并有可找回的结果入口。 - 有可测进度才显示百分比；没有可靠总量时使用明确的处理状态。不能伪造进度、长期停在接近完成处，或反复重置进度。 - 根据实际耗时决定提示出现与消失时机，避免短任务闪烁；不为展示读条人为延长任务，也不把所有操作都套上加载遮罩。 - 长等待要有真实出口：可取消时允许取消，可离开时保留任务，失败时说明影响并提供可执行的恢复方式。无穷旋转和永久禁用不能充当恢复设计。 ## 失败由程序先处理 对暂时性故障使用有边界的自动重试与退避。超过本轮自动恢复预算后，普通缓存保存保留最新数据、版本与 `dirty`，由既有同步机制在条件恢复后继续；独立远端命令保留原操作身份和恢复依据。结束无效的忙碌表现，只在用户需要知道损失、影响或作出决定时显示简短提示。恢复不要求用户反复点击、重启应用或重新走完整流程。 独立远端业务的结果未知、已确认成功、已确认失败分别处理。未知不能当作失败重新扣费，也不能当作成功删除记录。恢复可由重连、重新进入或后台任务触发；持久操作不能随某个面板销毁而失去跟踪。这不要求普通缓存保存额外建立逐业务动作的待确认状态。 独立远端命令缺少可靠幂等、查询或对账能力时，不自动重提有副作用的请求。保留原操作与待确认入口，并为无法自动确认的情况提供明确的处理渠道；不能承诺未确认资源一定能立即释放。 协调差异时仅处理相关对象，保留当前有效的本地状态与尚未同步的修改。不能为了内部保存或对账强制退出游戏、关闭所有页面、回填旧字段值或整体回退。确实无法继续的鉴权或数据恢复问题按最小必要范围处理，保留可恢复进度并诚实提示。 仅隐藏报错、删除仍有效的独立远端命令或资源占用记录、提前解锁冲突资源或无限重试都不能作为“无感修复”。这不要求保留普通云存档中冗余的逐动作待确认类型与记录；可在授权范围内移除，并由既有同步机制保留最新待同步数据。界面继续操作与最终数据一致必须同时成立。 ## 阻止验收与发布的问题 以下情况属于必须修复的交互缺陷，不能只列为后续体验优化；本次交付范围内出现任一项，修复并复验前不得通过验收或发布： - **非设计性全局阻塞**：内部同步、计算或恢复把本可继续的操作一起禁用。必要的整体等待必须有前述无法继续的依据，不能用补一个读条代替解除无关操作的限制。 - **受阻却不知道怎么办**：用户看不到真实处理状态，或没有可执行的离开、返回、取消或恢复入口。必要等待必须同时明确状态、最小限制范围、失败收尾和恢复入口。 - **永久待确认**：原操作长期占用资源或功能，超过自动恢复预算后仍没有有效的确认、处理渠道与可找回的状态。保留原操作身份和数据保护，由程序或明确的处理渠道继续收尾，不能只让用户反复等待或重试。 - **无限读条或残留锁定**：失败、超时、取消或流程结束后，加载遮罩、输入限制或忙碌状态仍不解除。必须结束无效等待，并保留继续核对未知结果的能力。 - **保存回滚或误清新修改**：普通缓存保存失败、超时或收到旧回执后，业务数据被旧值覆盖，后续操作被撤销，或较新的 `dirty` 被清除。必须保留最新状态并交回既有同步模块处理，不能用逐动作补偿掩盖数据丢失。 发现范围外的同类问题时记录具体影响与责任归属，不擅自扩大写入或发布权限。不能为满足流畅性要求移除真实远端业务所需的幂等、资源预留或权威结果校验。 ## 验证与交付 设计阶段明确可观察的用户行为及失败去向；实现与审查阶段按风险执行 [交互与恢复验收场景](references/acceptance-scenarios.md) 中适用的场景，不为简单改动套用全部检查。 至少回答：用户点击后看到什么、等待期间还能做什么、结果失败或未知时如何收尾。涉及持久化或副作用时，还要证明操作不丢失、不重复，重进后可恢复。 交付说明给出实际检查的交互、目标环境、数据规模和结果。将设计审阅、代码验证、真实运行与最终用户验收分别说明；增加 Skill 不能当作已有产品问题已经修复。