[!info] related notes

• 所属 MOC: 前端性能优化 MOC
• 前置概念: performance-monitoring-system
• 并列概念: skeleton-screen
• AI 对话应用: AI 对话中的 Optimistic UI

乐观更新

一句话定义

乐观更新是用户操作后先更新本地 UI，再异步提交服务器，实现”让用户感觉响应更快”的优化技术。

角色边界

本页是 Optimistic Update / Optimistic UI 的通用 canonical concept：只维护“先提交本地预期状态，再由远端结果确认或回滚”的核心机制、成立条件和失败边界。AI 对话里涉及临时消息 ID、assistant 流式占位和重试状态的组合细节放在 AI 对话中的 Optimistic UI。

核心内容

适用场景

• 点赞/收藏
• 勾选/开关
• 排序/拖拽
• 表单提交
• 评论发布

实现思路

1. 用户操作 → 立即更新本地 UI（乐观）
2. 同时发送异步请求
3. 成功：确认更新
4. 失败：回滚到之前的状态

示例

function handleLike() {
  // 1. 立即更新 UI
  setLiked(!liked);
  
  // 2. 发送请求
  api.toggleLike(id).catch(() => {
    // 3. 失败回滚
    setLiked(!liked);
    toast.error('操作失败');
  });
}

核心原则

• 只对可逆操作做乐观更新
• 失败必须回滚
• 考虑并发冲突

边界与易混淆点

乐观更新 vs 骨架屏

• 骨架屏：解决加载时的感知
• 乐观更新：解决交互时的感知
• 两者都是”感知优化”，不改变实际速度

学习检查

1. 乐观更新成立的前提为什么通常包括“可预测、可回滚或可补偿”？
2. 服务端失败后，客户端为什么不能只弹错误而不处理本地状态？
3. 乐观更新与 skeleton/loading state 分别优化哪一类等待？
4. AI 对话中的乐观消息为什么需要额外的身份和状态收敛机制？

Related notes

• 前端工程化MOC
• 前端基础MOC
• CSS MOC
• ECMAScript MOC