React Fiber 与 Hooks 深度协同机制

本文基于 React 19 的源码视角，深入剖析 Fiber 架构与 Hooks 机制如何深度协同工作。我们将遵循一个完整的更新生命周期，从用户交互触发更新开始，到最终 DOM 渲染，详细拆解其中的每一个环节。

Fiber 与 Hooks 的连接点

Fiber 节点是连接组件状态 (Hooks) 和渲染工作流的桥梁。两个核心属性构成了这一连接：

• Fiber.memoizedState: 这是 Hooks 链表的入口。对于一个函数组件的 Fiber 节点，其 memoizedState 属性指向该组件中第一个 Hook 对象的引用。后续的 Hook 对象通过 next 指针形成一个单向链表。

  // 简化概念：Fiber 节点的 memoizedState
  // fiber.memoizedState -> hook1 -> hook2 -> null
  // hook1 = { memoizedState: state1, queue: ..., next: hook2 }
  // hook2 = { memoizedState: state2, queue: ..., next: null }

• Fiber.updateQueue: 这个属性具有双重职责：

  1. 承载 Effects 链表：对于 useEffect 和 useLayoutEffect，它们创建的 Effect 对象会形成一个环形链表，并挂载到 Fiber.updateQueue 上。这使得 React 在提交阶段可以高效地遍历和执行副作用。
  2. 类组件的更新队列：对于类组件，它存储了 setState 或 forceUpdate 产生的更新。

  注意：useState 和 useReducer 的更新队列是存储在各自 Hook 对象自身的 queue 属性中，而不是直接在 Fiber.updateQueue。

4.2 状态更新的完整生命周期（Fiber-Hooks 视角）

让我们通过一个具体的用例，追踪一次状态更新的完整旅程。

用例：一个简单的计数器

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

  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);

  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

阶段一：更新发起与调度 (Scheduling)

1. 用户点击按钮：onClick 事件触发，调用 setCount(count + 1)。
2. 创建更新对象：setCount (内部为 dispatch 函数) 会创建一个 Update 对象。这个对象包含了更新的优先级（在现代 React 中由 Lane 表示）和 payload（在这里是 count + 1）。
3. 入队更新：该 Update 对象被添加到 count 这个 useState Hook 内部的更新队列 (hook.queue) 中。
4. 调度更新：React 调用 scheduleUpdateOnFiber。此函数会：
   • 从当前 Fiber 节点开始，向上遍历到根节点 (FiberRoot)。
   • 为本次更新分配一个 Lane，标记在 FiberRoot 上，表示有待处理的工作。
   • 请求调度器（Scheduler）安排一次新的渲染任务。

[流程图：从 setCount 到调度任务]setCount(1) -> 创建 Update 对象 {lane, payload} -> 加入 hook.queue -> scheduleUpdateOnFiber -> 标记 RootLane -> 请求 Scheduler 回调

阶段二：协调 (Reconciliation / Render Phase)

调度器在浏览器空闲时，会执行 React 的渲染任务，入口是 performUnitOfWork，它驱动着一个工作循环 (workLoop)。

1. beginWork：工作循环从根节点开始，自顶向下处理 Fiber 节点。当处理到 Counter 组件的 Fiber 节点时，beginWork 会调用 updateFunctionComponent。

2. renderWithHooks: 这是函数组件渲染和 Hooks 处理的核心。React 19 在这里进行了大量优化，但核心逻辑保持一致。

   • 初始化：currentlyRenderingFiber 指向当前 Counter 的 Fiber 节点。workInProgressHook 指针被重置。
   • “复制”并遍历 Hooks 链表：React 会从 workInProgress.alternate (即 current 树中对应的 Counter Fiber) 的 memoizedState 中找到旧的 Hooks 链表，并开始遍历。
   • 执行 useState：
     • updateState (或 updateReducer) 被调用。
     • 它会检查此 Hook 的更新队列 (hook.queue)，应用所有待处理的 Update，计算出新的 state 值（1）。
     • 返回新的 state 值 1。
   • 执行 useEffect：
     • updateEffect 被调用。
     • 它会比较新的依赖项 [1] 和旧的依赖项 [0]。
     • 因为依赖项发生了变化，React 会在当前 Fiber 节点的 flags 属性上添加 Passive 和 Update 标记 (workInProgress.flags |= Passive | Update)。这“预约”了在提交阶段需要执行此 Effect。
   • 执行组件函数：使用新的 count 值（1）重新执行 Counter 函数，得到新的 React Element (<button>1</button>)。
   • Diffing：beginWork 的最后一步是 reconcileChildren，它会将新返回的 Element 与旧的 Fiber 子节点进行比较。在这里，它会发现 <button> 的子文本节点内容从 0 变成了 1，因此会给该文本节点的 Fiber 标记一个 Update 的副作用。

3. completeWork：当 Counter 的子节点（button 和其文本子节点）都处理完毕后，completeWork 会被调用。

   • 构建 effectList：completeWork 会将带有副作用标记（flags）的 Fiber 节点（在这里是 Counter 的 Fiber 和其文本子节点）添加到一个单向链表 effectList 中。
   • 冒泡 flags：子节点的 flags 会被合并到父节点的 subtreeFlags 中，用于快速跳过没有副作用的子树。

[流程图：协调阶段 Hooks 链表的遍历与更新]beginWork(Counter) -> renderWithHooks -> 遍历 Hooks 链表 -> updateState (计算新 state) -> updateEffect (比较依赖，标记 flags) -> reconcileChildren (diff 子节点，标记 flags) -> completeWork -> 构建 effectList

阶段三：提交 (Commit Phase)

当整个 workInProgress 树都完成了 completeWork，React 就进入了同步的、不可中断的提交阶段。

1. 遍历 effectList：React 不再遍历整个树，而是直接遍历在 completeWork 中构建好的 effectList。
2. DOM 操作 (Mutation)：
   • React 遍历 effectList，根据 flags 执行所有 DOM 的增、删、改操作。
   • 在这个例子中，它会找到带有 Update 标记的文本节点，并将其内容更新为 1。
3. useLayoutEffect 执行：在 DOM 更新后，浏览器绘制前，同步执行所有 useLayoutEffect 的清理和创建函数。
4. 浏览器绘制：浏览器现在可以安全地绘制更新后的 DOM。
5. useEffect 执行：在浏览器绘制完成后，React 会异步地调度一个任务来执行所有 useEffect 的副作用。
   • 清理函数执行：首先，执行上一次渲染保存的清理函数：document.title 的操作没有清理函数，但如果是事件监听等，会在这里被移除。
   • 副作用函数执行：然后，执行本次渲染的 create 函数，即 document.title = 'Count: 1'。

[流程图：提交阶段与 Effect 执行]Commit Root -> 遍历 effectList -> 执行 DOM 更新 -> (useLayoutEffect) -> 浏览器绘制 -> 异步执行 useEffect 清理 -> 异步执行 useEffect 创建

4.3 错误边界与 Hooks

如果 Hooks 在执行过程中（例如，在 useState 的更新函数或 useEffect 的 create 函数中）抛出错误，React 的错误处理机制会被激活：

1. 捕获错误：在 renderWithHooks 或 commitPassiveEffectDurations 等函数的 try...catch 块中，错误被捕获。
2. 寻找错误边界：React 会从出错的 Fiber 节点开始，沿 return 指针向上遍历，寻找最近的错误边界（定义了 getDerivedStateFromError 或 componentDidCatch 的类组件）。
3. 中断并回退：当前的 Render/Commit 过程被中断。React 会开始一个新的、渲染回退 UI 的渲染流程，从找到的错误边界开始。

这确保了单个组件中的错误不会导致整个应用程序崩溃，体现了 Fiber 架构的健壮性。

---