React 并发原语：在并发模式下，多次 setState 产生的多个 Update 对象是如何在 pending 队列中合并的？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同学，把手里的咖啡放下，把手机静音，今天我们要聊的，是 React 内部最“混沌”、最迷人，也最让人头秃的地方——并发模式下的状态合并。

想象一下，你是一个拥有超能力的办公室主管。你的手下有无数个员工（组件），他们都在拼命地想要改变公司的数据（状态）。如果只是简单地让他们大喊大叫，办公室就会变成菜市场。为了维持秩序，我们需要一个严格的流程，把所有的喊叫打包，按优先级处理，最后才交给老板（渲染器）。

在 React 并发模式中，这个“流程”就是 pending 队列和 Update 对象的博弈。

准备好了吗？让我们潜入 React 的深海，去看看那些被我们调用的 setState 到底经历了什么。

第一部分：混乱的源头——为什么要排队？

在并发模式之前，setState 就像是一个不知疲倦的搬运工，你扔给它一个包裹，它立马就跑过去。如果用户手速快，或者浏览器卡顿，这个搬运工就会在同一个渲染周期里被召唤无数次。结果就是：同一个渲染周期里，状态被修改了十次，但 UI 只刷新了一次。 这就是所谓的“状态堆积”。

并发模式来了，它引入了时间片。React 像个严厉的监工，把渲染任务切碎了，切成了一个个小片段。这时候问题就来了：如果在切蛋糕的过程中，有人又往盘子里加了一块蛋糕，这块蛋糕该怎么处理？

是覆盖原来的？还是加在后面？还是得先看看这块蛋糕的“优先级”高不高？

这就是我们今天要讲的核心：Update 对象是如何在 Fiber 的 pendingQueue 队列中合并的。

第二部分：乐高积木——Update 对象

首先，我们需要认识一下这些“积木”。每次你调用 setState，React 并不是简单地把新状态扔进数组，而是会创建一个 Update 对象。

这个对象长得有点像下面这样（为了方便理解，我简化了源码结构）：

class Update {
  constructor(lane, payload, callback) {
    this.lane = lane; // 优先级车道（这是并发模式的关键！）
    this.payload = payload; // 新的状态值
    this.callback = callback; // 更新后的回调
    this.next = null; // 链表指针，指向下一个积木
  }
}

注意这个 next 指针！ 这意味着 pending 队列不是数组，而是一个单向链表。

为什么是链表？因为 React 需要快速地追加和移除元素。在链表头部插入元素是 O(1) 复杂度，而数组在中间插入是 O(n)。在 React 这种高频调用的场景下，链表是性能优化的选择。

第三部分：Fiber 的“待办事项”列表——pendingQueue

每个 React 组件实例，在内部都有一个对应的 Fiber 节点。这个 Fiber 节点就像组件的“大脑”，它记录了组件当前的快照（memoizedProps）、状态（memoizedState）以及未处理的任务。

这个“未处理的任务”队列，就是我们今天的主角：pendingQueue。

在源码中，Fiber 节点有一个属性叫 pendingQueue，它指向链表的头部。

// FiberNode 结构简化
class FiberNode {
  // ... 其他属性
  pendingQueue = null; // 指向 Update 对象链表的头部
}

当多个 setState 被调用时，React 并不会立刻去计算新的状态，而是把所有的 Update 对象塞进这个 pendingQueue 里。

第四部分：打包过程——enqueueUpdate

当一个 Update 对象被创建后，它怎么进队？这就涉及到 enqueueUpdate 函数。这个函数虽然名字叫“加入更新”，但它其实非常狡猾。

它的逻辑大概是这样的：

检查当前是否正在渲染：如果 React 正在渲染这个组件（比如在执行 render 函数），那么这些更新会直接合并到当前的渲染结果中，不需要排队。
创建 Update 对象：根据传入的参数，构造出那个 Update 实例。
挂载到链表：把它挂到 pendingQueue 的末尾。

// 伪代码：enqueueUpdate 的核心逻辑
function enqueueUpdate(fiber, update) {
  // 1. 如果当前没有队列，那就创建一个，把 update 放进去
  if (fiber.updateQueue === null) {
    fiber.updateQueue = {
      baseState: fiber.memoizedState, // 初始状态
      firstUpdate: null,              // 链表头
      lastUpdate: null,               // 链表尾
      lanes: 0,                       // 优先级掩码
    };
    fiber.updateQueue.lastUpdate = update;
    fiber.updateQueue.firstUpdate = update;
  } else {
    // 2. 如果队列已存在，直接挂到末尾
    const queue = fiber.updateQueue;
    queue.lastUpdate.next = update;
    queue.lastUpdate = update;
  }
}

这里有个细节： React 还会维护一个 baseState。baseState 记录的是组件上次渲染完成时的状态。而 pendingQueue 里存的是增量。

比如，组件初始状态是 { count: 0 }。
你调用了两次 setState：

setState({ count: 1 }) -> Update1: partialState = { count: 1 }
setState({ count: 2 }) -> Update2: partialState = { count: 2 }

此时，pendingQueue 里存的是 Update1 和 Update2。baseState 是 { count: 0 }。

第五部分：重头戏——processUpdateQueue（合并的艺术）

好了，积木都进队了，接下来就是最精彩的部分：当 React 准备渲染时，它怎么把这些积木拼起来？

这个过程由 processUpdateQueue 函数负责。这是 React 并发模式中最复杂的逻辑之一。它的任务就是把 baseState 和 pendingQueue 里的所有 Update 合并，生成最终的 memoizedState。

我们来看一段源码级别的伪代码，这段代码会解释“合并”到底是怎么发生的。

function processUpdateQueue(workInProgress, props, instance, renderLanes) {
  const queue = workInProgress.updateQueue;
  if (queue === null) {
    return;
  }

  // 初始化变量
  let newState = queue.baseState;
  let firstUpdate = queue.firstUpdate;
  let lastUpdate = queue.lastUpdate;
  let updateLaneQueue = null; // 优先级队列

  // --- 核心循环：遍历所有积木 ---
  if (firstUpdate !== null) {
    // 我们需要重新遍历一遍 pendingQueue
    // 注意：React 为了性能，可能会在循环中移除已经处理的更新
    let update = firstUpdate;
    do {
      // 1. 获取优先级
      const lane = update.lane;
      // 2. 检查优先级是否满足当前渲染要求
      // 如果 update 的优先级比 renderLanes 低，说明它被挂起了，跳过
      if (!isSubsetOfLanes(renderLanes, lane)) {
        // 如果是高优先级的 update，我们需要把它从队列中拿出来，放到优先级队列里
        // 这是一个复杂的逻辑，这里简化处理
        if (updateLaneQueue === null) {
          updateLaneQueue = lane;
        } else {
          mergeLanes(updateLaneQueue, lane);
        }
        // 标记这个 update 已经处理过了（通过移动指针）
        const nextUpdate = update.next;
        update.next = null;
        update = nextUpdate;
      } else {
        // --- 优先级满足，开始合并状态 ---

        // 情况 A：这是 replaceState
        if (update.hasOwnProperty('replaceState')) {
          newState = typeof update.payload === 'function' 
            ? update.payload.call(instance, newState) 
            : update.payload;
        } 
        // 情况 B：这是普通 setState（追加）
        else {
          // 核心逻辑： newState = newState + update.payload
          // 对于对象，是合并；对于函数，是执行；对于数字，是累加
          if (typeof update.payload === 'function') {
            // 如果 payload 是函数，它接收当前状态 newState，返回新状态
            const nextState = update.payload.call(instance, newState);
            newState = nextState !== null && nextState !== undefined ? nextState : newState;
          } else {
            // 如果 payload 是对象，这是对象合并的关键！
            // Object.assign(newState, update.payload)
            // 等同于 { ...newState, ...update.payload }
            newState = {
              ...newState,
              ...update.payload,
            };
          }
        }

        // 移动指针，防止死循环
        const nextUpdate = update.next;
        update.next = null;
        lastUpdate = update;
        update = nextUpdate;
      }
    } while (update !== null);

    // 3. 清理已处理的更新
    // 如果队列里有剩余的低优先级更新（被挂起的），我们保留它们
    if (lastUpdate === null) {
      queue.firstUpdate = null;
    } else {
      queue.firstUpdate = lastUpdate.next;
      lastUpdate.next = null;
    }
  }

  // 4. 更新 Fiber 的状态
  workInProgress.memoizedState = newState;
  workInProgress.lanes = updateLaneQueue || queue.lanes;
}

1. 对象的合并

这是最常用的场景。假设你有一个状态对象 state = { count: 1, name: 'Alice' }。

你调用了两次 setState：

setState({ count: 5 }) -> Update1
setState({ name: 'Bob' }) -> Update2

在 processUpdateQueue 中，第一次循环 newState 变成 { count: 5, name: 'Alice' }。
第二次循环，update.payload 是 { name: 'Bob' }。
代码执行 newState = { ...newState, ...update.payload }。
结果：newState 变成了 { count: 5, name: 'Bob' }。

注意： 这里是浅合并（Shallow Merge）。如果 count 是一个对象，它只会替换引用，不会递归合并。

2. 函数的合并

这是 React 的“魔法”所在。如果你传的是函数，React 会把它们串起来执行。

状态：state = { count: 0 }
调用：setState(prev => ({ count: prev.count + 1 })) 和 setState(prev => ({ count: prev.count + 2 }))

在队列中，这两个 Update 都持有 payload 函数。
执行顺序：

第一个函数执行，传入 { count: 0 }，返回 { count: 1 }。
第二个函数执行，传入 { count: 1 }（这是上一步的结果），返回 { count: 3 }。
最终结果：{ count: 3 }。

3. replaceState

还有一种特殊的 Update，它的标记是 replaceState。这通常用于 Class 组件中调用 this.setState(state => state) 或者某些内部逻辑。它会完全替换掉 baseState，而不是基于它进行合并。

第六部分：优先级之战——高优先级吃掉低优先级

这部分是并发模式最“性感”的地方。我们在 processUpdateQueue 的循环中看到了 isSubsetOfLanes 的判断。

想象一下，你正在渲染一个列表（低优先级任务），突然用户点击了一个“删除”按钮（高优先级任务）。

高优先级更新入队：setState({ isDeleted: true }) 被创建，标记为高优先级，加入 pendingQueue。
低优先级渲染进行中：React 正在遍历 pendingQueue 里的旧更新。
优先级检查：React 发现队列头部的更新是低优先级的，正准备处理。
打断：调度器发现有一个高优先级任务插队了！
中断与重置：React 立即中断当前的渲染，把当前 pendingQueue 里已经处理过的更新（低优先级）清空，把高优先级更新放回队列的头部。
重新渲染：React 重新开始渲染，这次优先处理那个“删除”按钮的更新。

这就是“合并”的另一种形式： 高优先级的更新会“覆盖”掉低优先级更新在本次渲染周期内产生的效果，或者至少确保高优先级更新先被处理。

第七部分：实战演练——看着代码“发呆”

为了让你更直观地理解，我们来写一个模拟的 React 组件逻辑，不依赖 React 库本身，只看数据流。

// 模拟组件
const MyComponent = () => {
  // 初始状态
  let fiber = {
    memoizedState: { count: 0, message: 'Hello' },
    updateQueue: {
      baseState: { count: 0, message: 'Hello' },
      firstUpdate: null,
      lastUpdate: null,
      lanes: 0
    }
  };

  // 模拟用户疯狂点击按钮 3 次
  const handleClick = () => {
    const update1 = { lane: 1, payload: { count: 1 }, next: null };
    const update2 = { lane: 1, payload: { message: 'World' }, next: null };
    const update3 = { lane: 1, payload: { count: 2 }, next: null };

    // 简单的链表挂载
    fiber.updateQueue.lastUpdate.next = update1;
    fiber.updateQueue.lastUpdate = update1;
    fiber.updateQueue.lastUpdate.next = update2;
    fiber.updateQueue.lastUpdate = update2;
    fiber.updateQueue.lastUpdate.next = update3;
    fiber.updateQueue.lastUpdate = update3;
  };

  // 模拟 React 的 processUpdateQueue
  const render = () => {
    const queue = fiber.updateQueue;
    let newState = queue.baseState;
    let update = queue.firstUpdate;

    console.log("--- 开始渲染 ---");

    while (update) {
      console.log(`处理 Update: ${update.payload.message || update.payload.count}`);

      // 简单的合并逻辑
      newState = {
        ...newState,
        ...update.payload
      };

      update = update.next;
    }

    // 更新组件的 memoizedState
    fiber.memoizedState = newState;
    console.log(`最终状态:`, newState);
    console.log("--- 渲染结束 ---n");
  };

  // 执行
  handleClick(); // 状态堆积
  render();      // 触发渲染，进行合并
  handleClick(); // 再次堆积
  render();      // 再次合并（此时队列里已经有之前的更新了）
};

输出结果预测：

--- 开始渲染 ---
处理 Update: 1
处理 Update: World
处理 Update: 2
最终状态: { count: 2, message: 'World' }
--- 渲染结束 ---

--- 开始渲染 ---
处理 Update: 1
处理 Update: World
处理 Update: 2
最终状态: { count: 2, message: 'World' }
--- 渲染结束 ---

看到了吗？虽然我们点击了两次，每次都调用了 setState，但在渲染的那一刻，React 把所有的 Update 对象像剥洋葱一样一层层剥开，最终把状态合并成了一个干净的 { count: 2, message: 'World' }。

第八部分：幽灵更新与 Callback

还有一个很有意思的细节。在 Update 对象中，有一个 callback 字段。

this.callback = () => {
  console.log('更新完成啦！');
};

当你调用 setState(a, b) 中的第二个参数 b 时，它就是这个 callback。React 会把 callback 存进 Update 对象。

在 processUpdateQueue 的最后，React 会遍历所有处理过的更新，按顺序执行这些回调。

// 在 processUpdateQueue 结尾
let update = queue.firstUpdate;
while (update !== null) {
  if (update.callback !== null) {
    update.callback.call(instance); // 执行回调
  }
  update = update.next;
}

这就是为什么你在 setState 的回调里能看到最新的 state（因为渲染流程已经走完了）。

第九部分：链表的重构与内存管理

React 并不是每次渲染都创建一个新的链表。它会尽量重用 pendingQueue。

在 processUpdateQueue 中，你会发现 React 会把处理过的更新从链表中“剪掉”（通过修改 firstUpdate 和 lastUpdate 指针）。

if (lastUpdate === null) {
  queue.firstUpdate = null; // 没有剩余更新了，清空头指针
} else {
  queue.firstUpdate = lastUpdate.next; // 保留未处理的更新
  lastUpdate.next = null; // 断开连接
}

这样做有两个好处：

性能：不需要每次都遍历整个历史更新队列，只处理新的。
内存：防止内存泄漏，旧的更新对象会被垃圾回收（GC）回收。

第十部分：总结一下

好了，伙计们，让我们把镜头拉远。

在 React 并发模式中，setState 不仅仅是赋值，它是一场接力赛。

起点：你调用 setState。
入队：React 创建一个 Update 对象，把它扔进 Fiber 节点的 pendingQueue 链表。此时，状态并没有改变，只是排队了。
渲染：当渲染周期到来，React 调用 processUpdateQueue。
合并：它拿着 baseState（初始状态），去遍历 pendingQueue。
- 如果是对象，就合并属性。
- 如果是函数，就串行执行函数。
- 如果是高优先级，就打断低优先级。
输出：生成最终的 memoizedState，更新 UI。

这就是为什么你在 React 里可以放心大胆地连续调用 setState，而不用担心状态错乱。因为 React 内部已经帮你把所有混乱的请求，整理得井井有条。

所以，下次当你看到控制台里的一堆状态更新，或者看到组件在并发模式下闪烁时，你要知道，那是成千上万个 Update 对象正在 pendingQueue 里排队，等待着被 processUpdateQueue 这位老司机驾驶着合并成最终的胜利果实。

代码不会撒谎，逻辑也不会撒谎。只要你理解了链表和合并，React 的并发模式就不再是黑盒，而是一个你可以随时打开的、精密的瑞士钟表。

好了，今天的讲座就到这里。大家回去可以试着写几个 setState，看看它们在控制台里到底是怎么“排队”的。如果有问题，下课再来问。下课！