乐观更新
Optimistic Update
高级通用乐观更新（Optimistic Update）是发出修改请求后，先在界面上呈现预计成功的结果，再根据服务器响应确认或修正。它解决了等待接口返回时操作显得迟钝的问题，例如点收藏后，图标可以立刻变亮。
你可能会说：「我点完收藏想马上看到图标变化，不用等接口返回；如果没保存成功，再恢复原样并告诉我。」
动手看看文章收藏的即时反馈
如何建立自己的阅读清单阅读指南 · 约 6 分钟
收藏文章
尚未收藏
收藏请求进度
悬停、按住或用 Tab 聚焦收藏按钮，看看即时反馈；再把请求进度切到「已点击，等待响应」，模拟点击后的界面变化。
未收藏时按钮保持普通外观，用户能看出这篇文章还不在阅读清单里。
要点先显示结果后，怎样保证它是对的？
- 1
先改界面，再等服务器确认
你点收藏时，前端可以先把图标点亮，同时发送请求。因为不用等网络往返，操作看起来更及时；但此时服务器还没确认，界面显示的只是预计结果。
- 2
失败时恢复并说明原因
如果请求失败，我们要把这次预先改动恢复，并告诉你收藏没有保存成功。否则图标亮着、服务器却没有记录，刷新页面后状态又变了，你会以为产品丢了数据。
- 3
连续操作要避免恢复错状态
如果你快速点了两次收藏，较早的请求可能更晚才返回。我们需要识别响应属于哪次操作，避免一次失败把后续成功的结果也撤销；复杂场景下也可以重新获取服务器状态。
容易混淆的地方
乐观更新不等于缓存：缓存是保存已有数据供后续读取，乐观更新是在服务器确认前暂时显示预计的新数据。它也不等于撤销：撤销是用户主动取消操作；这里的恢复通常由请求失败触发。服务器仍是最终结果的依据。
什么时候用
适合用
- 在文章列表做收藏或点赞，成功概率较高，又希望用户点下去就看到状态变化。
- 在任务看板移动卡片，先让卡片出现在新列，再等待位置保存结果。
- 在设置页切换普通偏好，先呈现新状态，保存失败时恢复并提示。
不适合用
- 支付、转账或下单确认不适合先显示交易已成功；等服务器确认后再展示结果。
- 删除不可恢复的重要资料时，不适合先当作已删除；先确认操作，再按服务器结果更新界面。
- 如果只是打开另一个页面，没有提交数据要等待，就直接导航，不需要乐观更新。
练一练选一个答案，看看解释
你在做任务看板。用户把卡片拖到“已完成”列后，保存位置的接口可能失败。哪种处理最符合乐观更新？
让 AI 帮你做复制给 AI Agent 直接用
请给任务看板的卡片拖动加入乐观更新：拖放后立即更新界面并提交位置，失败时恢复该次操作并提示用户。考虑连续拖动和请求乱序，避免旧响应覆盖较新的结果；成功后以服务器返回的数据为准。