乐观 UI 在服务器确认变更前先更新界面，把流程从“点击→请求→响应→更新界面”改为“点击→立即更新界面→请求→确认或回滚”，让产品感觉更快，但把复杂度转移到回滚、对账和失败处理上。
适用场景：点赞、收藏、开关等小型可逆状态；添加评论或消息；排序；更新标签或偏好；标记已读或完成。应避免或限制：支付与金融操作、无撤销的破坏性操作、库存受限操作、权限敏感变更、复杂服务端校验。高风险变更可先显示待处理状态而不改最终 UI，或只对本地外壳乐观、不提交真实数据，或提供撤销而非静默回滚。
变更生命周期：捕获用户意图、保存撤销所需信息、本地应用乐观补丁、标记为待处理、发送变更、与服务器响应合并、清除待处理或失败回滚。核心构件包括乐观补丁、回滚信息（保存快照或反向补丁）、待处理元数据（用于禁用重复提交、显示同步状态、防止过期响应覆盖新意图）、服务器对账（响应为权威真相，可能含服务端 ID、净化文本、时间戳、派生计数、权限或校验调整）。
常见模式：切换变更（点赞、书签、完成状态）；用临时 ID 创建（如 temp-${Date.now()}，成功后替换为真实记录，失败则移除）；排序回滚（先本地重排，失败恢复原顺序）；计数更新（同时修补记录与聚合，但并发常见时应以服务器返回计数为准）；基于缓存的乐观更新（取消或暂停竞争性重新获取、快照旧值、写入乐观值、失败回滚、最后失效或替换为服务器真相，具体 API 因 TanStack Query、SWR、Apollo、Relay 等而异，生命周期相同）。
并发与竞态：乱序响应、重复提交、冲突的本地编辑、后台重新获取覆盖。防御手段包括附加客户端请求 ID、忽略早于最新本地意图的过期响应、对同一记录按顺序排队、使用版本号或 updatedAt、在乐观补丁活跃时暂停或协调重新获取。
回滚策略：完全回滚（恢复快照，适合简单切换、单记录编辑、排序）；部分回滚（保留部分本地 UI，只修正服务器拥有的字段，适合草稿表单、复杂编辑器）；用撤销代替回滚（立即接受并短暂提供撤销，适合归档、移入回收站、忽略）。
UX 指南：用降低不透明度、发送中标签、禁用后续破坏性操作、失败重试等细微指示显示待处理；让失败可见，如内联错误、重要操作用提示加重试、状态可能已变时用撤销或冲突提示；若乐观失败频繁，功能会显得损坏，高成功率适合乐观 UI，频繁校验或权限失败应改用保守待处理 UI。
后端支持幂等变更端点、稳定资源标识、返回权威记录、版本字段或时间戳、区分校验/授权/冲突的清晰错误码，会让前端乐观更安全。决策清单：用户意图是否立即明确、变更是否可逆或易纠正、失败是否相对罕见、能否安全恢复先前状态、服务器能否返回权威数据用于对账；若多项为否，优先快速待处理状态而非真正乐观提交。相关技能包括 state-management-patterns、data-fetching-patterns、routing-patterns。