I3.02.1optimistic UI divergence设计
乐观更新提高响应感但可能与真实不符
别名: 乐观 UI · 先本地后确认 · optimistic update · 假成功
概念解释
点赞立刻亮、评论立刻出现、开关立刻翻面——界面先按「请求会成功」改本地，网络结果后到。这种做法叫乐观更新（optimistic update）。它买到的是响应感：动作和后果仍被编成一件事。它欠下的是一段分叉窗口：屏幕上的世界与服务器上的世界暂时不是同一个。窗口里，用户以为已经完成的事，可能根本没写上。
这条只谈这笔交易值不值得做。适不适合用在不可逆动作上、失败之后怎么说话，是另外的问题。
机制
人机对话里，反馈若晚过大约百分之一秒，动作和结果会被拆成两件事；晚过一秒，思路开始断。跨网络的写操作几乎注定超出这两条缝，所以产品把「已写上」的像素先画出来，用本地状态填缝。服务器应答是第二拍：确认则窗口闭合，屏幕与真实重合；拒绝则窗口变成债务——屏幕说过的话要收回。
分叉窗口的伤害随被当成真的程度上升。点赞亮一下，人可能再点一次，代价小。列表里多出一条「已发送」的消息，人会离开这个线程去做下一件事，代价是后续决策建在假事实上。乐观策略能成立，靠的是失败率足够低，低到分叉被当成偶发，而不是系统的常态谎言。失败率一高，响应感这笔账就被不信任冲掉。
边界
只读刷新、搜索建议、滚动位置，没有「先当成功」可乐观的，不在范围里。本地就能裁定的操作（纯界面折叠、未同步的草稿）本来就不是乐观，是真本地。强一致账本、库存为 1 的抢购、多人同时改同一格子，失败不是偶发，乐观会把冲突窗口拉到用户已经走远之后才爆。弱网或明确离线时，用户对「先记下」有预期，分叉被当成排队而不是欺骗——前提是界面承认还没到达服务器，而不是画成已经到达。
怎么落地
- 只对失败率低、可撤回、不触发下一步不可逆决策的写入做乐观：点赞、已读、排序、短评论。
- 乐观态与已确认态要能区分给需要核对的人看（例如「发送中」相对「已送达」），不要把两态画成完全一样的成功。
- 统计真实失败率。持续高于几个百分点，先修网络或权限，而不是继续用乐观遮延迟。
- 验证：把写接口固定返回错误，点一次「看起来会成功」的操作。若界面先画成成功、过一阵又无解释地变回去，响应感已经用分叉买到了，但交易不成立——要么别乐观，要么必须把分叉当事件处理。再开慢网：从按下到像素变化应仍在即时窗口内，服务器往返可以后到。