React useState 更新路径解析：从 dispatchAction 到微任务队列的完整流程

各位编程专家，大家好！今天我们将深入探讨 React useState 钩子的更新机制。useState 是 React Hooks 提供的核心功能之一，它让函数组件拥有了管理自身状态的能力。然而，当我们调用 setState 函数时，幕后到底发生了什么？从一个简单的状态更新请求，到最终浏览器屏幕上 UI 的变化，这中间涉及了 React 复杂的调度、协调和渲染流程。我们将层层剖析，从 dispatchAction 的起点，追溯到更新任务如何被调度、执行，并最终澄清其与微任务队列的关系。

1. 声明式 UI 与状态管理的核心

React 的核心思想是声明式 UI。我们告诉 React UI 应该是什么样子，而不是如何一步步去改变它。当数据（即状态）发生变化时，React 会自动处理 UI 的更新。useState 就是 React 中管理组件局部状态的主要方式，它使得函数组件能够持有并更新状态，从而驱动 UI 的重新渲染。理解其内部机制，对于深入掌握 React 性能优化和复杂交互至关重要。

2. useState：声明式状态的入口

useState 钩子允许我们在函数组件中添加状态。它接收一个初始状态值作为参数，并返回一个包含当前状态值和更新该状态的函数的数组。

2.1 useState 的基本用法

import React, { useState } from 'react';

function Counter() {
  // count 是当前状态值，setCount 是更新状态的函数
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1); // 直接传入新值
  };

  const decrement = () => {
    // 传入一个函数，接收前一个状态作为参数，返回新状态
    setCount(prevCount => prevCount - 1);
  };

  return (
    <div>
      <p>当前计数: {count}</p>
      <button onClick={increment}>增加</button>
      <button onClick={decrement}>减少</button>
    </div>
  );
}

在这个例子中，setCount 就是我们触发状态更新的入口。当 setCount 被调用时，React 会启动一系列内部流程来响应这个变化。

2.2 setState：触发更新的函数

setCount（或任何由 useState 返回的第二个元素）实际上是一个包装器，它最终会调用 React 内部的一个核心函数，我们可以称之为 dispatchAction。这个函数是所有 useState 和 useReducer 状态更新的统一入口。它的职责是接收用户提供的更新（新值或更新函数），将其封装成一个内部数据结构，并将其添加到组件的更新队列中，然后通知 React 调度器有新的工作需要处理。

3. React 内部更新架构概览：Fiber 与调度器

在深入 dispatchAction 之前，我们需要对 React 的核心更新架构有一个高层次的理解。这包括 Fiber 架构、渲染与提交阶段以及调度器。

3.1 Fiber 架构：可中断的协调器

React 16 引入了 Fiber 架构，彻底改变了其内部协调（reconciliation）算法。Fiber 是对 React 元素（React Element）的运行时表示，它是一个 JavaScript 对象，包含了组件的类型、状态、属性以及指向其父节点、子节点和兄弟节点的指针。

Fiber 的核心作用：

• 链表结构： Fiber 节点以单向链表的形式连接，可以高效地遍历组件树。
• 工作单元： 每个 Fiber 节点代表一个“工作单元”，React 可以独立地处理、暂停或恢复对它的处理。
• 双缓冲： React 维护两棵 Fiber 树：
  • current 树： 代表当前屏幕上渲染的 UI 状态，与真实 DOM 同步。
  • workInProgress 树： 在后台构建的新树，代表即将要渲染的 UI 状态。所有的更新和协调工作都在这棵树上进行。
    当 workInProgress 树构建完成并通过协调，并且可以安全地提交时，它会替换掉 current 树。

Fiber 架构使得 React 能够实现可中断的渲染，从而支持并发模式和时间切片，提高了用户体验。

3.2 渲染阶段与提交阶段

React 的更新流程主要分为两个阶段：

1. 渲染阶段 (Render Phase / Reconciliation Phase)：

   • 这是一个“纯”阶段，不会产生副作用（如修改 DOM）。
   • React 会遍历 workInProgress Fiber 树，调用组件的 render 方法（对于函数组件，就是执行其函数体），计算出新的 UI 状态。
   • 在这个阶段，useState 的更新函数会被应用，计算出新的状态值。
   • 这个阶段可能被暂停或中断，然后稍后恢复。

2. 提交阶段 (Commit Phase)：

   • 这是一个“副作用”阶段，会执行 DOM 操作和生命周期方法（如 useLayoutEffect、useEffect）。
   • React 会将 workInProgress 树中计算出的差异（changes）应用到真实 DOM 上，使得 UI 与新的状态同步。
   • 这个阶段是同步且不可中断的。

3.3 调度器 (Scheduler)：任务优先级与并发模式

React 的调度器 (Scheduler) 是一个独立的包 (react-scheduler)，它负责管理和优化 React 内部的更新任务。它的核心目标是：

• 优先级： 为不同的更新任务分配不同的优先级（例如，用户输入事件的优先级高于网络请求数据的更新）。
• 时间切片： 将高优先级的任务拆分成小块，在浏览器空闲时执行，避免长时间阻塞主线程，从而保持 UI 的响应性。
• 协作式调度： 与浏览器协作，利用 requestIdleCallback (或更精确的 MessageChannel) 等 API，在浏览器帧的空闲时间执行任务。

当 setState 被调用时，dispatchAction 会通知 React 调度器，从而启动整个更新流程。

4. 深入 dispatchAction：创建与入队更新

现在，让我们回到 setState 调用的起点，深入了解 dispatchAction 的内部工作。

4.1 寻找更新目标：Fiber 与 Hook

当 setState 被调用时，React 需要知道这个更新是针对哪个组件、哪个 useState 钩子的。

1. currentlyRenderingFiber： 在组件函数执行期间（即渲染阶段），React 会内部追踪当前正在渲染的 Fiber 节点。setState 调用通常发生在事件处理函数或副作用中，这些上下文会提供组件的 Fiber 信息。
2. hook 对象： 每个 Fiber 节点内部都有一个链表，存储着该组件使用的所有 Hooks。当我们调用 useState 时，React 会在 Hook 链表中找到对应的 hook 对象。这个 hook 对象包含了该 useState 实例的状态值、更新队列等信息。

// 概念性代码：Fiber 节点和 Hook 对象的简化表示
class FiberNode {
  // ... 其他属性
  memoizedState: any; // 存储 Hooks 链表的头部
  // ...
}

class Hook {
  memoizedState: any; // 当前 Hook 的状态值
  queue: UpdateQueue; // 该 Hook 的更新队列
  next: Hook; // 指向下一个 Hook
  // ...
}

4.2 Update 对象：更新的承载者

每一次 setState 调用都会创建一个 Update 对象。这是 React 内部表示状态变化的基本单元。

一个 Update 对象通常包含以下关键信息：

• lane (或旧版 expirationTime)： 表示这个更新的优先级。React 使用“车道（Lanes）”模型来管理优先级，不同的 lane 代表不同的优先级。例如，用户交互（点击）通常具有高优先级，而数据获取可能具有中等优先级。
• action： 这是你传递给 setState 的实际内容。它可以是一个新的状态值（如 count + 1），也可以是一个更新函数（如 prevCount => prevCount - 1）。
• next： 指向下一个 Update 对象。因为一个 useState 钩子可能在短时间内接收多个更新，这些更新会被组织成一个单向链表。

// 概念性代码：Update 对象的简化表示
class Update {
  lane: Lane; // 更新的优先级
  action: any; // 更新动作：新值或更新函数
  next: Update | null; // 指向下一个 Update
  // ...
}

4.3 UpdateQueue：更新的队列

每个 useState 钩子（更准确地说，是其对应的 hook 对象）都维护着一个 UpdateQueue。当 dispatchAction 创建一个 Update 对象后，它会将其添加到这个 UpdateQueue 中。

UpdateQueue 的结构通常是一个循环链表，其中 pending 属性指向链表的最后一个 Update。这样做的目的是为了方便在队列头部添加新的更新，并能快速访问到所有更新。

// 概念性代码：UpdateQueue 的简化表示
class UpdateQueue {
  pending: Update | null; // 指向最后一个待处理的 Update
  lastRenderedReducer: Function | null; // 用于 functional update
  lastRenderedState: any; // 上次渲染时的状态
  // ...
}

4.4 源码探秘：dispatchAction 核心逻辑 (概念性)

让我们用伪代码来模拟 dispatchAction 的核心流程：

// 假设这是 React 内部的 dispatchAction 函数
function dispatchAction(fiber, hook, lane, action) {
  // 1. 创建一个新的 Update 对象
  const update = {
    lane: lane,
    action: action,
    next: null,
  };

  // 2. 获取该 Hook 的 UpdateQueue
  const queue = hook.queue;
  if (queue === null) {
    // 这不应该发生，因为 hook.queue 在 useState 初始化时已经创建
    console.error("Hook queue is null!");
    return;
  }

  // 3. 将新的 Update 添加到 UpdateQueue 的循环链表中
  const pending = queue.pending;
  if (pending === null) {
    // 队列为空，新 Update 既是第一个也是最后一个
    update.next = update;
  } else {
    // 将新 Update 插入到 pending 之后，并更新 pending 的 next 指针
    update.next = pending.next;
    pending.next = update;
  }
  queue.pending = update; // 更新 pending 指向新的最后一个 Update

  // 4. 调度更新：通知 React 调度器有新的工作需要处理
  // 这一步是关键，它会将 Fiber 标记为需要更新，并触发调度流程
  scheduleUpdateOnFiber(fiber, lane);
}

// 在 useState 内部，setCount 函数会调用 dispatchAction
function useState(initialState) {
  // ... 内部逻辑，获取当前 Fiber 和 Hook
  const hook = /* 获取当前 Hook 对象 */;
  const fiber = /* 获取当前 Fiber 对象 */;

  function setCount(action) {
    // 确定更新的优先级 (lane)，这里简化为默认优先级
    const lane = getDefaultUpdateLane();
    dispatchAction(fiber, hook, lane, action);
  }

  return [hook.memoizedState, setCount];
}

通过这个 dispatchAction，我们的状态更新请求就被封装成了 Update 对象，并被成功地加入了对应 useState 钩子的 UpdateQueue。接下来，就是调度器登场的时候了。

5. 调度更新：从 UpdateQueue 到 Scheduler

dispatchAction 的最后一步是调用 scheduleUpdateOnFiber，这标志着更新流程从数据结构操作转向了任务调度。

5.1 scheduleUpdateOnFiber：标记与优先级

scheduleUpdateOnFiber 函数会执行以下关键操作：

1. 确定优先级 (Lane)： 它会再次确认这次更新的优先级 lane。
2. 标记 Fiber： 它会将当前 Fiber 节点以及其所有祖先节点（一直向上追溯到根 Fiber 节点）标记为具有该 lane 优先级。这意味着所有被标记的 Fiber 节点都需要在接下来的渲染阶段中被检查和处理。
3. 获取根 Fiber： 它会找到当前更新所关联的根 Fiber 节点 (HostRootFiber)。所有更新都是从根节点开始协调的。

// 概念性代码：scheduleUpdateOnFiber 的简化逻辑
function scheduleUpdateOnFiber(fiber, lane) {
  // 1. 将当前 Fiber 及其祖先 Fiber 标记为需要更新
  // 这确保了在协调时，从根节点开始可以找到所有需要处理的路径
  markUpdateLaneFromFiberToRoot(fiber, lane);

  // 2. 找到根 Fiber 节点
  const root = getRootForFiber(fiber);
  if (root === null) return;

  // 3. 确保根节点被调度器安排处理
  ensureRootIsScheduled(root, lane);
}

5.2 ensureRootIsScheduled：通知调度器

ensureRootIsScheduled 是将 React 内部的更新请求传递给 react-scheduler 模块的关键函数。它的主要职责是：

1. 计算根节点的 pendingLanes： 根 Fiber 节点会维护一个 pendingLanes 掩码，表示所有待处理更新的优先级。
2. 判断是否需要调度： 如果根节点已经有更高优先级的任务正在处理，或者当前任务优先级不够高而无法中断现有任务，那么可能不需要立即调度。否则，它会通知调度器。
3. 调用 Scheduler.scheduleCallback： 这是与 react-scheduler 模块交互的核心。它会将一个回调函数（通常是 performSyncWorkOnRoot 或 performConcurrentWorkOnRoot，用于启动渲染阶段）以及更新的优先级传递给调度器。

// 概念性代码：ensureRootIsScheduled 的简化逻辑
function ensureRootIsScheduled(root, lane) {
  // ... 逻辑判断是否需要调度 ...

  // 告诉调度器，有一个高优先级的任务需要执行
  // Scheduler.scheduleCallback 会返回一个 Task 对象
  const task = Scheduler.scheduleCallback(Scheduler.UserBlockingPriority, () => {
    // 这个回调函数就是 React 真正开始协调和渲染的入口
    performSyncWorkOnRoot(root); // 或者 performConcurrentWorkOnRoot
  });
  root.callbackNode = task; // 存储任务节点，以便取消或检查
}

5.3 调度器的工作原理：宏任务与时间切片

现在我们来到了最关键的环节之一：react-scheduler 如何将这个回调函数放入浏览器事件循环中，以及它与宏任务/微任务队列的关系。

5.3.1 浏览器的事件循环：宏任务与微任务

在深入 React 调度器之前，快速回顾一下浏览器的事件循环 (Event Loop) 概念至关重要：

• 主线程： 浏览器只有一个 JavaScript 主线程，负责执行 JavaScript 代码、处理用户事件、执行渲染等。
• 任务队列 (Task Queue / Macro-task Queue)： 存放各种异步任务，如 setTimeout、setInterval、setImmediate (Node.js)、I/O 操作、UI 渲染、MessageChannel 等。每次事件循环迭代，主线程会从任务队列中取出一个任务执行。
• 微任务队列 (Micro-task Queue)： 存放更高优先级的异步任务，如 Promise.then()、MutationObserver。在每次主线程执行完一个宏任务之后，并且在下一个宏任务开始之前，会清空微任务队列。

执行顺序：
一个宏任务执行完毕 -> 清空所有微任务 -> 渲染（如果需要） -> 执行下一个宏任务。

5.3.2 React Scheduler 的实现机制：MessageChannel

React 的 Scheduler 模块在浏览器环境中，为了实现其时间切片和优先级调度，主要依赖 MessageChannel API 来调度任务，而不是 requestIdleCallback (因为 requestIdleCallback 的调度不够及时和可控，延迟可能较大)。

MessageChannel 允许我们创建一个新的消息通道，并发送消息。当消息被发送时，它会在浏览器事件循环中作为一个宏任务被排队。

Scheduler.scheduleCallback 的简化流程：

1. Scheduler.scheduleCallback 接收一个优先级和一个回调函数。
2. 它会将这个回调函数包装成一个 Task 对象。
3. 然后，它会使用 MessageChannel 创建一个消息端口，并向其发送一个消息。
4. 当 MessageChannel 的 port.onmessage 事件被触发时（这发生在下一个宏任务中），Scheduler 会检查当前是否有高优先级任务需要执行，以及是否有时间剩余。
5. 如果有时间，它会执行之前注册的回调函数（即 performSyncWorkOnRoot 或 performConcurrentWorkOnRoot）。
6. 如果任务执行时间过长，或者有更高优先级的任务插入，Scheduler 会暂停当前任务，并在下一个 MessageChannel 宏任务中继续执行，或者调度更高优先级的任务。

5.3.3 setState 更新与宏任务队列

关键结论： 默认情况下，setState 触发的 React 更新流程，其核心调度机制 (react-scheduler 使用 MessageChannel) 是将更新任务放入宏任务队列中，而不是微任务队列。

这意味着：

1. 当你调用 setState 时，dispatchAction 会将更新添加到 UpdateQueue。
2. scheduleUpdateOnFiber 会标记 Fiber 树。
3. ensureRootIsScheduled 会通过 Scheduler.scheduleCallback 向 MessageChannel 发送消息。
4. 这个 MessageChannel 的消息处理函数会在当前宏任务执行完毕后，并且清空微任务队列后，在下一个宏任务中被浏览器调用。
5. 在这个宏任务中，performWorkOnRoot 才会被执行，开始 React 的渲染阶段。

这种基于宏任务的调度，使得 React 的渲染工作能够与其他浏览器任务（如用户输入、网络请求）和谐共处，实现非阻塞的并发更新。

6. 渲染阶段：执行组件逻辑与计算新状态

一旦 Scheduler 决定执行 React 的渲染任务（通过调用 performWorkOnRoot），整个渲染阶段便开始了。

6.1 performWorkOnRoot：根节点的协调入口

performWorkOnRoot 是渲染阶段的起点。它会负责：

1. 初始化 workInProgress 树：如果这是第一次渲染或上一次渲染被中断，它会从 current 树克隆出 workInProgress 树。
2. 设置渲染上下文：例如，当前时间切片的截止时间，以便 workLoop 知道何时暂停。
3. 调用 renderRootSync 或 renderRootConcurrent：根据当前的调度模式（同步或并发）启动实际的协调工作循环。

6.2 workLoop：遍历 Fiber 树

workLoop 是渲染阶段的核心循环。它会从根 Fiber 节点开始，深度优先遍历 workInProgress Fiber 树。

在遍历过程中，它会不断调用 performUnitOfWork 来处理每个 Fiber 节点。如果时间片用尽，workLoop 会暂停，将控制权交还给浏览器，并在下一个调度器任务中恢复。

6.3 performUnitOfWork：单个 Fiber 的处理

performUnitOfWork 是处理单个 Fiber 节点的函数。它主要分为两个阶段：

1. beginWork (向下遍历阶段)：

   • 处理当前 Fiber 节点的属性和状态。
   • 对于函数组件，会调用其函数体。
   • 根据新的 props 和 state，决定是否需要协调子节点。
   • 创建或更新子 Fiber 节点，并返回第一个子 Fiber。

2. completeWork (向上归阶段)：

   • 如果 beginWork 没有返回子节点（即当前节点是叶子节点），或者所有子节点都已处理完毕，则进入 completeWork。
   • 在这个阶段，React 会根据当前 Fiber 的类型（如 div、span 或自定义组件），创建或更新对应的真实 DOM 元素（如果是 host 组件）。
   • 处理副作用标记（如 Placement、Update、Deletion），这些标记会在提交阶段被用来执行 DOM 操作。

6.4 renderWithHooks：函数组件的灵魂

当我们讨论 useState 时，beginWork 阶段中最关键的部分就是对函数组件的处理，即调用其函数体。这发生在 renderWithHooks 函数中。

renderWithHooks 会在执行函数组件之前，设置好 React 内部的 Hook 上下文（例如，currentlyRenderingFiber 和 workInProgressHook 指针）。然后，它会执行你的函数组件。

当函数组件内部调用 useState() 时，React 会：

1. 找到对应的 Hook： 在 currentlyRenderingFiber 的 memoizedState 链表中找到与当前 useState 调用位置对应的 hook 对象。
2. 处理 UpdateQueue： 从 hook.queue.pending 中取出所有待处理的 Update 对象。
3. 计算新状态： 按照它们被添加到队列的顺序，逐一应用这些 Update 对象来计算出最新的状态值。
   • 如果 action 是一个值，直接使用该值。
   • 如果 action 是一个函数（prevCount => prevCount - 1），则调用该函数，并传入当前已计算出的状态值。
4. 更新 memoizedState： 将计算出的最新状态值存储到 hook.memoizedState 中。
5. 返回状态值： useState 返回这个最新的状态值。

6.4.1 核心状态计算：处理 UpdateQueue

这是一个简化的状态计算过程：

// 概念性代码：在 renderWithHooks 中处理 UpdateQueue
function reconcileUpdates(hook, currentFiber, workInProgressFiber) {
  const queue = hook.queue;
  const pendingQueue = queue.pending;

  if (pendingQueue !== null) {
    // 将 pending 队列清空，表示这些更新即将被处理
    queue.pending = null;

    // 获取上一次渲染的状态作为初始值
    let baseState = hook.memoizedState;
    // 如果有 baseState 相关的优化，这里也会处理

    // 从第一个 Update 开始遍历
    let firstUpdate = pendingQueue.next;
    let update = firstUpdate;

    do {
      const updateLane = update.lane;
      // ... 检查 updateLane 是否在当前渲染的 lane 范围内 ...

      const action = update.action;
      if (typeof action === 'function') {
        // 如果是函数式更新，调用函数并传入当前状态
        baseState = action(baseState);
      } else {
        // 如果是直接值，直接使用
        baseState = action;
      }
      update = update.next;
    } while (update !== null && update !== firstUpdate); // 循环链表

    // 更新 Hook 的 memoizedState
    hook.memoizedState = baseState;
    // 记录上次渲染的 reducer 和 state，用于下次计算
    queue.lastRenderedReducer = null; // 简化处理，实际会记录
    queue.lastRenderedState = baseState;
  }
  return hook.memoizedState; // 返回计算出的最新状态
}

// 在 renderWithHooks 内部，当 useState 被调用时：
// ...
// const newState = reconcileUpdates(hook, currentFiber, workInProgressFiber);
// return [newState, dispatch];
// ...

至此，渲染阶段完成了新 workInProgress Fiber 树的构建，其中包含了所有组件的最新状态和属性，以及与旧 current 树的差异。但这些变化还没有反映到真实 DOM 上。

7. 提交阶段：真实 DOM 操作与副作用执行

渲染阶段完成后，如果 workInProgress 树被成功构建，React 就会进入提交阶段。这个阶段是同步的，不可中断，因为它会直接修改真实 DOM。

7.1 commitRoot：提交的起点

commitRoot 是提交阶段的入口函数。它会负责调度和执行提交阶段的三个子阶段。

7.2 提交阶段的三个子阶段

React 将提交阶段分为三个子阶段，以确保副作用的执行顺序和时机正确：

7.2.1 Before Mutation (前置变更)

• 执行 getSnapshotBeforeUpdate： 在真实 DOM 发生任何变更之前，React 会调用类组件的 getSnapshotBeforeUpdate 生命周期方法。这允许组件在 DOM 更新前捕获一些信息（如滚动位置），这些信息在 componentDidUpdate 中可能不再可用。
• 执行 useLayoutEffect 的清理函数： 如果有 useLayoutEffect 钩子，它的上一次渲染的清理函数会在这个阶段被执行。

7.2.2 Mutation (变更)

• 执行 DOM 操作： 这是提交阶段的核心。React 会遍历 workInProgress 树中带有副作用标记的 Fiber 节点，并根据这些标记执行真实的 DOM 操作：
  • 插入 (Placement)： 将新的 DOM 节点插入到文档中。
  • 更新 (Update)： 更新现有 DOM 节点的属性、文本内容等。
  • 删除 (Deletion)： 从文档中移除不再需要的 DOM 节点。
• 执行 useLayoutEffect 的设置函数： 在 DOM 已经更新但浏览器还未绘制前，useLayoutEffect 的设置函数会同步执行。这对于测量 DOM 布局等操作非常重要。

7.2.3 Layout (布局)

• 调用生命周期方法：
  • componentDidMount (对于挂载的类组件)
  • componentDidUpdate (对于更新的类组件)
• 执行 useEffect 的清理函数和设置函数： 在整个提交阶段和 DOM 更新完成后，浏览器绘制之前，useEffect 的清理函数会被执行，然后其设置函数会在一个新的宏任务中异步执行。这使得 useEffect 不会阻塞浏览器的绘制，但可能会导致视觉上的微小延迟。

7.3 更新 current 树

提交阶段的最后一步是，将 workInProgress 树设置为新的 current 树。这意味着 workInProgress 树现在代表了屏幕上最新的 UI 状态。旧的 current 树则会被废弃。

至此，整个 React 内部的更新流程完成，真实 DOM 已经更新，浏览器可以进行下一步的绘制操作，将最新的 UI 呈现在用户面前。

8. 澄清微任务队列与 flushSync

在讲解 setState 更新路径时，我们特别强调了其默认调度机制是基于宏任务队列的。然而，用户提到了“进入微任务队列”，这确实是一个常见的混淆点，值得详细澄清。

8.1 默认 setState 更新与微任务队列的关系

明确的答案是：默认情况下，setState 触发的 React 渲染更新流程，其核心调度机制并不会将渲染工作直接放入微任务队列。

如前所述，React 的 Scheduler 模块在浏览器环境中主要利用 MessageChannel 来调度更新任务。MessageChannel 发送消息后的回调是作为一个宏任务被排队的。这意味着：

• 当你调用 setState 时，它会同步地将 Update 对象添加到 UpdateQueue，并标记 Fiber 树。
• 然后，它会通过 Scheduler 异步地安排一个宏任务来执行实际的渲染工作 (performWorkOnRoot)。
• 这个宏任务会在当前 JavaScript 堆栈清空、所有微任务队列被清空后，才会被浏览器执行。

因此，如果你在 setState 之后立即执行一个 Promise.resolve().then(...)，那么 Promise 的回调（一个微任务）会比 React 的渲染宏任务更早执行。

console.log('1. 开始');

setTimeout(() => console.log('5. setTimeout (宏任务)'), 0);

Promise.resolve().then(() => console.log('3. Promise.then (微任务)'));

// 假设在一个事件处理函数中调用 setState
// 通常这个 setState 会在当前事件宏任务结束后，通过 Scheduler 安排一个新的宏任务来执行渲染
function handleClick() {
  setCount(c => c + 1); // 触发 React 更新
  console.log('2. setState 被调用后');
  // 假设 React 的渲染任务是一个宏任务 R
}

console.log('4. 结束');

// 实际输出顺序（不考虑渲染绘制）：
// 1. 开始
// 2. setState 被调用后
// 3. Promise.then (微任务)
// 4. 结束
// 5. setTimeout (宏任务)
// (R. React 渲染宏任务)

从这个例子可以看出，微任务比 setTimeout 和 React 的渲染宏任务都要早执行。

8.2 flushSync：强制同步更新

尽管默认行为是异步调度（宏任务），React 提供了一个特殊的 API：ReactDOM.flushSync。

ReactDOM.flushSync(callback) 的作用是强制 React 在当前 JavaScript 任务中同步执行所有挂起的更新。这意味着：

1. 当你在 flushSync 的回调函数中调用 setState 时，这些更新会被立即处理，而不是被调度到未来的宏任务中。
2. React 会跳过 Scheduler 的异步调度机制，直接进入渲染阶段 (performSyncWorkOnRoot) 和提交阶段 (commitRoot)。
3. DOM 会立即更新。

import React, { useState } from 'react';
import ReactDOM from 'react-dom';

function FlushSyncExample() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    ReactDOM.flushSync(() => {
      setCount(prev => prev + 1);
      console.log('在 flushSync 内部，count:', count); // 注意：这里可能还是旧的 count，因为组件函数还没重新执行
    });
    console.log('flushSync 外部，DOM 应该已更新，但组件 state 可能滞后，count:', count);
    // 如果这里有 Promise.resolve().then()，它会在此处立即执行，
    // 在浏览器绘制 flushSync 引起的 DOM 变化之前
    Promise.resolve().then(() => {
        console.log('微任务：在 flushSync 之后，DOM 已更新，但可能在浏览器绘制之前');
    });
  };

  return (
    <div>
      <p>当前计数: {count}</p>
      <button onClick={handleClick}>增加 (flushSync)</button>
    </div>
  );
}

使用 flushSync 时，整个渲染和提交过程都在当前的 JavaScript 任务中同步完成。因此，如果你在 flushSync 之后立即安排一个微任务，这个微任务仍然会在浏览器绘制 flushSync 引起的 DOM 变化之前执行。flushSync 改变的是 React 内部的调度方式（从异步到同步），而不是它与微任务队列的交互顺序。

8.3 微任务队列在 React 中的角色（非更新调度本身）

虽然 React 的核心渲染调度不使用微任务队列，但微任务队列仍然在以下场景中与 React 更新流程交互：

1. 副作用的执行顺序： 如果你在一个 useEffect 或 useLayoutEffect 中，或者在组件函数中，手动安排了一个微任务（例如 Promise.resolve().then(...)），这个微任务会在当前组件函数或副作用执行完毕后，但在下一个宏任务（包括 React 调度器安排的宏任务）开始之前执行。
2. 与外部库的集成： 如果你使用的某些第三方库在内部使用了微任务来执行某些操作，那么这些操作的执行时机就会遵循微任务的规则，与 React 的渲染宏任务之间存在明确的优先级。
3. MutationObserver： 某些 React 内部机制可能会利用 MutationObserver（它也是微任务），例如在某些特定环境下检测 DOM 变化，但这不是 setState 更新调度的主流路径。

总结来说，useState 的更新路径通过 dispatchAction 将更新放入 UpdateQueue，然后通过 scheduleUpdateOnFiber 通知 Scheduler 安排一个宏任务来执行渲染工作。微任务队列并不直接参与 setState 的默认更新调度过程，但它在整个浏览器事件循环中扮演着更高优先级的角色，影响着其他 JavaScript 代码与 React 渲染任务的相对执行顺序。flushSync 则是绕过异步调度，强制同步执行更新的特殊手段。

9. 异常处理与并发特性简述

在整个更新流程中，React 也考虑了异常处理和未来的并发特性：

9.1 错误边界 (Error Boundaries)

如果在渲染阶段（renderWithHooks 执行组件函数时）发生未捕获的 JavaScript 错误，React 会向上冒泡寻找最近的错误边界组件。错误边界会捕获这些错误，并允许你渲染一个备用 UI，从而防止整个应用崩溃。

9.2 Suspense

Suspense 允许组件“暂停”渲染，直到某些异步数据准备好。当一个组件通过 throw Promise 的方式暂停时，React 会捕获这个 Promise，并渲染最近的 Suspense 边界提供的 fallback UI。当 Promise 解决后，React 会重新尝试渲染该组件。这同样是建立在 Fiber 架构的可中断渲染能力之上。

10. useState 更新的生命周期

从 dispatchAction 到屏幕上的 UI 变化，useState 的更新路径是一次精心设计的旅程：它始于一个简单的状态更新请求，通过 Update 对象和 UpdateQueue 记录下来。随后，scheduleUpdateOnFiber 将其传递给 react-scheduler，后者利用 MessageChannel 在未来的宏任务中安排渲染工作。在渲染阶段，React 遍历 Fiber 树，执行组件函数，并应用 UpdateQueue 中的所有更新来计算出新的状态。最终，在提交阶段，React 会同步地将这些变化应用到真实 DOM，并通过副作用钩子完成清理和数据同步，使 UI 呈现最新状态。这个复杂而高效的流程确保了 React 应用在保持高性能和响应性的同时，提供了声明式的开发体验。