欢迎来到“乐观 UI”的游乐场：如何在网络波动中假装一切都很完美

大家好，我是你们的老朋友，一个在 React 深渊里摸爬滚打多年的资深工程师。

今天我们不聊那些虚头巴脑的架构图，也不谈什么微前端、Serverless，咱们来聊点“人性”的东西。具体来说，咱们聊聊乐观更新。

你有没有过这种经历？你在电商网站上，手指悬停在“加入购物车”按钮上，心里默念“买买买”，然后手指一按——好了，购物车图标瞬间从 0 变成了 1。没有转圈圈，没有“加载中”，甚至没有一丝丝延迟。你心里那个爽啊，觉得这网站简直神了。

然后你淡定地继续浏览，甚至觉得自己刚才那一手操作简直行云流水，堪比魔术师。

但是，你有没有想过，服务器那边发生了什么？

服务器可能还在打哈欠，甚至可能因为网络波动正在给你发“请稍等”的信号。但你的浏览器早就替你决定了结果。这就是乐观更新的核心哲学：先发制人，甚至有点“欺骗”性质。

今天，我们就来扒一扒这个让用户体验起飞，却让后端调试头秃的技术。我们不讲枯燥的定义，我们直接上代码，上实战，上段子。

---

第一章：当“Loading”成为数字时代的噩梦

在谈乐观更新之前，我们必须先批判一下“悲观更新”。

什么是悲观更新？就是那种你点一下按钮，它就给你转圈圈，告诉你“正在努力连接宇宙中心，请稍候 3 秒”。3 秒过去了，还是转圈圈，最后你刷新页面，发现刚才的操作白费了。

这种体验，就像是你约了女神去吃饭，发消息过去，她回了个“嗯”，然后你就站在原地等着，时间一分一秒过去，你心里的焦虑像杂草一样疯长。女神不回消息，你就得在那傻等。这叫“等死”。

而在 Web 开发中，这种“等死”体验的罪魁祸首就是那个该死的 Loading 状态。

用户点个赞，等 2 秒；
用户发条评论，等 3 秒；
用户提交个表单，等 5 秒。

如果你的应用里充满了这种“转圈圈”，用户就会觉得你的应用很卡，甚至觉得你的代码写得像便秘一样。于是，乐观更新应运而生。它的口号是：如果用户相信你会成功，那你就先告诉他成功了。

这不仅仅是关于速度，这是关于掌控感。

---

第二章：乐观更新的本质——先吃蛋糕，再付钱

想象一下，你去面包店买蛋糕。

悲观模式（传统模式）： 你付钱，然后面包师拿刀切蛋糕，称重，装袋，再递给你。整个过程你都要盯着面包师，心里祈祷他手别抖，称别坏。如果你说“我要这块”，他得先问老板“这能卖吗？”，然后老板问系统“有库存吗？”，系统问数据库“还有吗？”。这一通下来，你都快饿死了，蛋糕凉了。

乐观模式（Optimistic UI）： 你指着蛋糕说“我要这个！”。面包师二话不说，直接切下一块塞你手里，收了钱，然后转身对你说：“先拿着，我去确认一下后厨还有没有。如果没了，你再把蛋糕吐出来。”

这就是乐观更新的精髓。它假设请求会成功，所以 UI 立即响应。如果真的成功了，皆大欢喜；如果失败了，再进行回滚。

在 React 中，这意味着我们要在数据还没到服务器之前，就更新本地状态。

---

第三章：原生 React 的“手动挡”实现

虽然现在有很多库（React Query, SWR）帮我们搞定了一切，但作为资深工程师，我们必须知道底层是怎么运作的。这就像你知道怎么用筷子，也知道怎么用叉子，但偶尔你也得知道怎么直接上手抓饭吃。

我们来看一个最简单的例子：点赞。

假设我们有一个帖子列表，每个帖子都有一个 likeCount。

3.1 悲观版本的代码（垃圾代码）

function Post({ post }) {
  const [likes, setLikes] = useState(post.likeCount);
  const [loading, setLoading] = useState(false);

  const handleLike = async () => {
    setLoading(true); // 开始转圈圈，用户体验下降
    try {
      // 发送请求
      await api.likePost(post.id);
      // 成功了才更新 UI
      setLikes(prev => prev + 1);
    } catch (error) {
      // 失败了给个提示
      console.error("点赞失败", error);
    } finally {
      setLoading(false); // 停止转圈圈
    }
  };

  return (
    <div className="post">
      <h3>{post.title}</h3>
      <p>点赞数: {loading ? '...' : likes}</p>
      <button onClick={handleLike} disabled={loading}>
        {loading ? '处理中...' : '点赞'}
      </button>
    </div>
  );
}

看到那个 loading 状态了吗？看到那个 disabled 了吗？看到那个 ... 了吗？这就是用户体验的杀手。用户感觉自己的操作被卡住了。

3.2 乐观版本的代码（真香代码）

现在，我们把它改成乐观更新。

function Post({ post }) {
  const [likes, setLikes] = useState(post.likeCount);

  const handleLike = async () => {
    // 1. 立即更新 UI（乐观部分）
    // 我们假装请求已经成功了
    setLikes(prev => prev + 1);

    try {
      // 2. 发送请求
      await api.likePost(post.id);
      // 如果请求成功，什么都不用做，UI 已经是新的了
    } catch (error) {
      // 3. 如果请求失败，回滚！
      // 把 UI 恢复到原来的样子
      setLikes(prev => prev - 1);

      // 给用户一点反馈（比如 Toast 提示）
      showToast("哎呀，点赞失败了，网络好像抽风了");
    }
  };

  return (
    <div className="post">
      <h3>{post.title}</h3>
      <p>点赞数: {likes}</p>
      <button onClick={handleLike}>点赞</button>
    </div>
  );
}

看，这就是区别。用户点击的瞬间，数字就变了。没有转圈圈。那种“噌”的一下，爽不爽？

---

第四章：React Query —— 资深工程师的“作弊码”

写原生代码虽然能理解原理，但每次都要手动处理 try/catch、手动处理 loading、手动处理回滚，太累了。而且容易出 bug。

这时候，TanStack Query (React Query) 就闪亮登场了。它简直就是为乐观更新量身定制的。

React Query 的 useMutation 钩子，自带了处理乐观更新的机制。

4.1 基础用法

import { useMutation, useQueryClient } from '@tanstack/react-query';

function LikeButton({ postId }) {
  const queryClient = useQueryClient();

  // 定义 mutation
  const mutation = useMutation({
    mutationFn: (postId) => api.likePost(postId),

    // onMutate：在请求发送前执行
    // 这里就是我们的“乐观”操作发生的地方
    onMutate: async (newPostId) => {
      // 1. 取消正在进行的查询，防止数据覆盖
      await queryClient.cancelQueries({ queryKey: ['posts', newPostId] });

      // 2. 保存旧数据（为了回滚）
      const previousPost = queryClient.getQueryData(['posts', newPostId]);

      // 3. 乐观更新本地缓存
      queryClient.setQueryData(['posts', newPostId], (old) => {
        return {
          ...old,
          likes: old.likes + 1
        };
      });

      // 返回上下文，供 onError 使用
      return { previousPost };
    },

    // onError：如果出错了，恢复旧数据
    onError: (err, newPostId, context) => {
      queryClient.setQueryData(['posts', newPostId], context.previousPost);
    },

    // onSettled：无论成功失败，都重新获取数据（保持最终一致性）
    onSettled: (data, error, newPostId) => {
      queryClient.invalidateQueries({ queryKey: ['posts', newPostId] });
    }
  });

  return (
    <button 
      onClick={() => mutation.mutate(postId)}
      disabled={mutation.isPending}
    >
      点赞 ({mutation.data?.likes || 0})
    </button>
  );
}

看到没？React Query 帮你处理了所有的脏活累活。
onMutate 是乐观更新的核心。它利用了 React Query 的缓存机制。React Query 把你的组件状态和服务器状态分离开来了。

• 组件状态： 乐观更新修改的是这个。
• 服务器状态： 等请求回来，或者重新获取。

4.2 为什么要用 invalidateQueries？

注意看 onSettled 里的 invalidateQueries。为什么我们不直接在成功后更新缓存，而要重新获取？

这就是最终一致性的问题。

乐观更新是一种“快照”。它假设成功了。但如果服务器因为并发问题（比如两个人同时点赞），拒绝了这个操作怎么办？或者服务器因为 bug 返回了错误怎么办？

为了确保我们的 UI 和服务器数据绝对一致（最终一致性），我们通常在乐观更新之后，触发一次数据的重新获取（或者使用乐观更新后的数据作为缓存，但这在复杂场景下很难保证）。invalidateQueries 会告诉 React Query：“去服务器重新拉取一下最新数据，覆盖掉我刚才那个可能错误的乐观更新。”

这就像你去餐厅点菜。乐观更新是你先吃了。invalidateQueries 就是服务员去厨房确认一下这道菜到底做好了没。如果厨房说没做好，服务员就会把菜撤走，重新给你上菜。

---

第五章：进阶场景——列表的“回滚”艺术

乐观更新不仅仅是修改一个数字，它还涉及到列表的增删改查。这里面有个大坑：索引问题。

场景：删除列表中的某一项

假设你有一个购物车，你点击删除按钮。

乐观更新逻辑：

1. 立即从本地列表中移除该项。
2. 显示“删除成功”的 Toast。
3. 发送请求到服务器。
4. 如果失败，把该项加回去。

代码大概是这样的：

const mutation = useMutation({
  mutationFn: deleteItem,
  onMutate: async (itemId) => {
    // 1. 取消查询
    await queryClient.cancelQueries({ queryKey: ['cart'] });

    // 2. 保存当前列表快照
    const previousData = queryClient.getQueryData(['cart']);

    // 3. 乐观更新：过滤掉要删除的项
    queryClient.setQueryData(['cart'], (oldData) => {
      return oldData.filter(item => item.id !== itemId);
    });

    // 返回上下文
    return { previousData };
  },
  onError: (err, itemId, context) => {
    // 4. 失败回滚：恢复旧数据
    queryClient.setQueryData(['cart'], context.previousData);
    showToast("删除失败，商品还在购物车里");
  },
  onSettled: () => {
    // 5. 重新获取
    queryClient.invalidateQueries({ queryKey: ['cart'] });
  }
});

这里的关键点在于 onError。如果你在乐观更新后没有保存 previousData，一旦出错，你根本不知道原来的列表长什么样，也就没法回滚了。

这就是原子性操作在 React 中的体现。要么全部成功，要么全部回滚。虽然网络请求失败了，但我们在 UI 层面保证了这种原子性。

---

第六章：并发更新与竞态条件

现在，让我们来点更刺激的。React 18 引入了并发模式。

想象一下，用户手速极快，连续点击了两次“点赞”按钮。

悲观模式：
用户点一次 -> Loading -> 请求 A 发送 -> 请求 B 发送 -> 请求 A 成功，UI 更新 -> 请求 B 成功，UI 再次更新（可能重复，或者覆盖） -> 用户一脸懵逼。

乐观模式 + 并发：
用户点一次 -> 请求 A 发送 -> UI 更新（+1）。
用户点一次 -> 请求 B 发送 -> UI 更新（+1）。
两个请求都成功了。UI 变成了 +2。这是正确的。

但是，如果请求 B 失败了怎么办？React Query 会自动处理这种竞态条件。它会丢弃过期的请求结果。

const mutation = useMutation({
  mutationFn: (id) => api.likePost(id),
  // React Query 默认会处理这种竞态问题
});

但是，如果我们手动实现乐观更新，就需要特别注意。比如，我们在 onMutate 里保存了 previousPost，但是用户在请求回来的过程中又点了两次，这时候 onError 拿到的上下文可能已经不是最新的了。

解决方案：
在 onMutate 中，不仅要保存数据，还要取消正在进行的查询。React Query 的 cancelQueries 已经帮我们做了这件事。如果我们手动管理状态，就得手动用 AbortController 取消请求。

const controller = new AbortController();

const mutation = useMutation({
  mutationFn: () => fetch('/api/like', { signal: controller.signal }),
  onMutate: async () => {
    controller.abort(); // 取消其他正在进行的类似操作
    // ... 乐观更新逻辑
  }
});

这有点像是在高速公路上开车，你变道了（发送了请求），必须把原来的车道锁住（取消之前的请求），否则后面的车（新的请求）会把你撞飞。

---

第七章：复杂表单的乐观更新

乐观更新在表单里怎么用？比如注册、修改资料。

直接把整个表单状态都乐观更新？那如果服务器要求必填项没填怎么办？如果密码太短怎么办？如果图片上传失败怎么办？

这时候，我们不能盲目乐观。

策略：

1. 部分乐观更新： 只更新 UI 上已经拿到服务器反馈的字段（比如头像上传成功后，显示新头像）。
2. 禁用按钮： 在提交表单期间，禁用按钮，防止重复提交。
3. 错误处理： 表单提交失败后，把错误信息显示在对应字段旁边。

function EditProfile({ user }) {
  const [form, setForm] = useState(user);
  const [isUpdating, setIsUpdating] = useState(false);
  const [error, setError] = useState(null);

  const handleSubmit = async (e) => {
    e.preventDefault();
    setIsUpdating(true);
    setError(null);

    try {
      // 乐观更新：假设成功
      // 实际上我们只是更新了本地状态
      // React 本身就是声明式的，所以 UI 会自动渲染新的表单值

      await api.updateUser(form);

      // 成功后刷新整个用户信息
      window.location.reload(); // 简单粗暴，或者用 React Query 刷新
    } catch (err) {
      // 失败了，回滚 UI
      setForm(user); 
      setError("更新失败，请检查输入");
    } finally {
      setIsUpdating(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input 
        value={form.name} 
        onChange={e => setForm({...form, name: e.target.value})}
        disabled={isUpdating}
      />
      <button disabled={isUpdating}>保存</button>
      {error && <span style={{color: 'red'}}>{error}</span>}
    </form>
  );
}

在这个例子中，我们乐观地更新了 form 状态。如果服务器返回 400 错误（比如用户名已存在），我们立即把 form 恢复成原来的 user。用户会看到输入框里的内容瞬间变回了修改前的样子，这给了用户很强的“失败反馈”。

---

第八章：保持“最终一致性”的哲学

回到我们的主题：在网络波动环境下维持 React 状态与服务端最终一致性。

乐观更新是一种暂时性的状态。它把服务器的“真理”推迟到了最后。

如果用户刷新页面，或者打开浏览器的开发者工具，或者被同事远程控制了电脑，乐观更新的状态就会消失，因为那只是内存里的假象。

如何保证最终一致性？

1. 乐观更新是 UI 的快照： 它是为了给用户看的，不是为了给数据库看的。
2. 请求回来后的清洗： 无论是成功还是失败，都要重新获取数据（invalidateQueries）。
3. 乐观更新不能替代数据验证： 前端乐观更新后，服务器必须再次验证数据的合法性。如果服务器验证失败，必须返回错误，前端负责回滚。

这就像你出门前收拾行李（乐观更新），觉得自己带齐了。但是当你到了机场，安检人员（服务器）说：“嘿，你忘带身份证了。” 这时候，你只能老老实实回家拿身份证（回滚），而不是站在机场大喊“我明明感觉我带了啊！”

---

第九章：实战演练——一个完整的购物车案例

为了让大家彻底理解，我们来写一个稍微复杂点的购物车组件。

需求：

1. 用户点击“加入购物车”。
2. 购物车数量立即 +1。
3. 显示一个绿色的“已添加”提示。
4. 如果请求失败，数量 -1，显示红色提示。
5. 如果请求成功，提示消失。

import { useMutation, useQueryClient } from '@tanstack/react-query';
import { useState } from 'react';

function ProductCard({ product }) {
  const queryClient = useQueryClient();
  const [toast, setToast] = useState(null); // { message: string, type: 'success' | 'error' }

  const mutation = useMutation({
    mutationFn: (productId) => api.addToCart(productId),
    onMutate: async (productId) => {
      // 1. 取消查询，防止冲突
      await queryClient.cancelQueries({ queryKey: ['cart'] });

      // 2. 获取旧数据
      const previousCart = queryClient.getQueryData(['cart']);

      // 3. 乐观更新
      queryClient.setQueryData(['cart'], (old) => {
        const existingItem = old.find(item => item.id === productId);
        if (existingItem) {
          return old.map(item => 
            item.id === productId ? { ...item, quantity: item.quantity + 1 } : item
          );
        } else {
          return [...old, { ...product, quantity: 1 }];
        }
      });

      // 4. 显示“添加中”的 Toast（乐观提示）
      setToast({ message: `已将 ${product.name} 加入购物车`, type: 'success' });

      // 返回上下文
      return { previousCart };
    },
    onError: (err, productId, context) => {
      // 5. 失败回滚
      queryClient.setQueryData(['cart'], context.previousCart);
      setToast({ message: '添加失败，请重试', type: 'error' });

      // 3秒后清除错误提示
      setTimeout(() => setToast(null), 3000);
    },
    onSuccess: () => {
      // 6. 成功后，延迟一点清除提示，让用户看到成功
      setTimeout(() => setToast(null), 1000);
    },
    onSettled: () => {
      // 7. 无论成功失败，重新获取数据（虽然乐观更新已经改了，但这是保险起见）
      queryClient.invalidateQueries({ queryKey: ['cart'] });
    }
  });

  const handleAddToCart = () => {
    mutation.mutate(product.id);
  };

  return (
    <div className="product-card">
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <button onClick={handleAddToCart} disabled={mutation.isPending}>
        {mutation.isPending ? '添加中...' : '加入购物车'}
      </button>

      {toast && (
        <div className={`toast toast-${toast.type}`}>
          {toast.message}
        </div>
      )}
    </div>
  );
}

在这个例子中，我们使用了 React Query 的上下文机制。onMutate 返回的 context 对象在 onError 中被重新赋值，实现了完美的回滚。

---

第十章：不要在所有地方都使用乐观更新

最后，作为一个资深专家，我得泼点冷水。乐观更新虽然好，但不是万能药。

什么时候不要用乐观更新？

1. 需要服务器 ID 的情况： 比如创建一条新评论，服务器返回了新的 ID。如果你乐观更新了列表，但你还没拿到新 ID，列表的渲染就会出错（比如用索引渲染，或者需要 ID 来定位）。这时候，你只能先显示一个占位符，等 ID 到了再替换。
2. 副作用巨大的操作： 比如删除账户、修改密码。这种操作一旦出错，后果很严重。用户可能会以为自己改成功了，结果过两天发现密码没变，或者账号被盗。这种情况下，老老实实等待服务器响应可能更安全。
3. 数据结构极其复杂： 如果你的状态更新涉及深层的嵌套对象，手动处理回滚的 previousState 会非常痛苦。这种时候，使用一个状态管理库（如 Redux）配合中间件来处理乐观更新会更合适。

---

结语：做一名“乐观”的工程师

好了，同学们，今天的讲座就到这里。

我们讲了什么是乐观更新，讲了如何用原生 React 实现，讲了如何用 React Query 进阶，讲了列表的回滚，讲了并发竞态，还写了一个完整的购物车案例。

乐观更新不仅仅是一个技术技巧，它是一种用户同理心。它告诉用户：“我相信你的操作是有价值的，我相信我们的系统是可靠的。”

在网络波动的时代，这种信任感是无价的。虽然我们作为工程师要时刻准备着处理错误和回滚，但只要我们逻辑严密、代码稳健，我们就可以放心大胆地让用户先享受成功的喜悦，然后再去处理现实。

记住，不要做那个只会转圈圈的悲观主义者。要做一名快乐的、乐观的、让用户爽到飞起的 React 工程师！

现在，去把你的 Loading 状态全部干掉吧！