React

引言：从同步渲染到并发时代

2013 年 React 横空出世时，它的渲染模型非常朴素：状态变更触发重新渲染，组件树被递归地计算出一棵新的虚拟 DOM 树，随后通过 Diff 算法找出差异并同步地提交到真实 DOM。这个"同步、不可中断"的模型在当时足够快，但随着应用规模膨胀、组件树达到数千节点，单次渲染动辄占用主线程几十甚至上百毫秒，用户输入、动画帧都被阻塞，"掉帧"和"卡顿"成为 React 大型应用的顽疾。React 团队在 2016 年提出的 Fiber 架构，以及 2022 年随 React 18 正式落地的并发特性（Concurrent Features），正是为了从根本上解决这一问题。理解 Fiber 与并发渲染，已经成为前端工程师进阶绕不开的一课。

一、为什么旧架构走不通了

旧版 React（Stack Reconciler，栈协调器）的致命缺陷在于渲染过程与 JavaScript 执行模型深度耦合。JavaScript 是单线程语言，渲染一旦开始，就会像"推倒的多米诺骨牌"一样执行到底：组件的 render 函数依次调用，Diff 计算、生命周期钩子逐一执行，中途无法暂停。假设一次更新耗时 100ms，那么在这 100ms 内，浏览器无法响应用户点击、无法绘制动画帧、无法处理网络回调。这对交互密集型应用是灾难性的。

问题的本质可以用一个公式概括：总耗时 = 渲染耗时 + 提交耗时。提交阶段（操作真实 DOM）本身不可分割，但渲染阶段（计算新旧树差异）其实是纯粹的计算，完全可以被打断、分片、恢复。Fiber 架构的核心思想，就是把渲染过程拆成一帧帧可以中断的小任务（时间切片），让浏览器在每个切片之间有机会处理更高优先级的工作。

二、Fiber 节点：新的数据结构基石

Fiber 架构的第一步是重新设计虚拟 DOM 的数据结构。每个 React 元素现在对应一个 Fiber 节点，它不仅描述"这个组件是什么"，还携带了大量调度相关的运行时信息：

function FiberNode(tag, pendingProps, key) {
  // 静态信息
  this.tag = tag;            // 组件类型：函数组件、类组件、HostComponent 等
  this.key = key;
  this.elementType = null;
  this.type = null;          // 组件本身（函数/类/字符串标签）
  this.stateNode = null;     // 对应的真实 DOM 或类组件实例

  // 链表结构：代替旧的递归树
  this.return = null;        // 父 Fiber（"return" 指调用返回处）
  this.child = null;         // 第一个子 Fiber
  this.sibling = null;       // 下一个兄弟 Fiber
  this.index = 0;

  // 工作单元信息：协调器的核心
  this.ref = null;
  this.pendingProps = pendingProps;
  this.memoizedProps = null; // 上一次渲染的 props
  this.updateQueue = null;   // 状态更新队列
  this.memoizedState = null; // 上一次渲染的 state（Hooks 链表挂在这里）
  this.dependencies = null;

  // 双缓冲：指向另一棵树的对应节点
  this.alternate = null;

  // 副作用标记：Diff 结果记录在此
  this.flags = NoFlags;
  this.subtreeFlags = NoFlags;
  this.lanes = NoLanes;      // 优先级车道
  this.childLanes = NoLanes;
}

注意三个关键设计。第一，链表代替递归树：child、sibling、return 三个指针把树变成可遍历的链表结构，遍历器因此可以随时"记住"当前处理到哪个节点，被打断后从断点恢复，而无需像递归那样把整个调用栈留在内存里。第二，双缓冲（Double Buffering）：每个 Fiber 节点通过 alternate 指针指向另一棵树上与自己对应的节点。React 始终维护 current 树（当前显示）与 workInProgress 树（正在构建），渲染完成后二者角色互换，避免了每次更新都重新从零分配内存。第三，副作用列表（Effect List / flags）：Diff 中发现需要变更的节点会被打上 flags 标记（Placement、Update、Deletion 等），提交阶段沿这条"副作用链"批量处理，把 DOM 操作集中化。

三、可中断的渲染循环：工作循环与调度器

Fiber 架构下，渲染（Reconcile）过程被组织成一个工作循环：

function workLoopConcurrent() {
  // 时间切片：只要还有剩余时间，就继续处理工作单元
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
  if (workInProgress !== null) {
    // 时间用尽，让出主线程，稍后继续
    scheduleCallback(NormalSchedulerPriority, performConcurrentWorkOnRoot);
    return;
  }
  if (!rootWithPendingPassiveEffects) {
    // 渲染完成，进入提交阶段
    finishConcurrentRender(root, ...);
  }
}

function performUnitOfWork(fiber) {
  // beginWork：处理当前节点，计算新的子 Fiber，返回下一个工作单元
  const next = beginWork(current, fiber, renderLanes);
  fiber.memoizedProps = fiber.pendingProps;
  if (next === null) {
    // 没有子节点，开始"完成"阶段并向上/向右遍历
    completeUnitOfWork(fiber);
  } else {
    workInProgress = next;
  }
}

shouldYield() 基于 Scheduler 的 deadline 检查当前帧的剩余时间（约 5ms 一个切片）。这与浏览器原生的 requestIdleCallback 思想一致，但 React 自己实现了 Scheduler 包，因为它需要更精细的优先级控制和跨浏览器一致性。Scheduler 的核心是基于小顶堆的任务队列：任务按优先级和到期时间排序，通过 MessageChannel 宏任务调度执行，每个宏任务内循环执行任务直到时间片耗尽，把控制权还给浏览器。

四、优先级系统：Lanes 模型

可中断渲染只是手段，决定"什么该被中断、什么该插队"的才是灵魂。React 18 引入了 Lanes（车道）模型，用 31 个二进制位表示 31 档优先级：

export const TotalLanes = 31;
export const NoLanes = 0b0000000000000000000000000000000;
export const SyncHydrationLane = 0b0000000000000000000000000000001;
export const SyncLane = 0b0000000000000000000000000000010;
export const InputContinuousHydrationLane = 0b0000000000000000000000000000100;
export const InputContinuousLane = 0b0000000000000000000000000001000;
export const DefaultHydrationLane = 0b0000000000000000000000000010000;
export const DefaultLane = 0b0000000000000000000000000100000;
export const TransitionHydrationLane = 0b0000000000000000000000001000000;
export const TransitionLanes = 0b0000000001111111111111110000000000;
export const RetryLanes = 0b0000111110000000000000000000000000;
export const SomeRetryLane = 0b0000010000000000000000000000000000;
export const SelectiveHydrationLane = 0b0001000000000000000000000000000000;
export const NonIdleLanes = 0b0001111111111111111111111111111111;
export const IdleHydrationLane = 0b0010000000000000000000000000000000;
export const IdleLane = 0b0100000000000000000000000000000000;
export const OffscreenLane = 0b1000000000000000000000000000000000;

不同事件天然携带不同优先级：离散用户输入（点击、按键）是 SyncLane，最高优先级，同步执行不可打断；连续输入（scroll、pointermove）是 InputContinuousLane；startTransition 包裹的更新是 TransitionLanes，可以被随时中断和丢弃重试。这种"用位掩码合并多个待处理更新"的设计，让 React 可以用 O(1) 的位运算完成优先级比较、合并与批处理——例如 lanes & (lanes - 1) === 0 判断是否只剩单一优先级。

五、双缓冲与提交阶段的不可打断性

渲染可以中断，但提交（Commit）不能。想象一半 DOM 已更新、一半未更新的中间状态，用户会看到撕裂的画面。因此 React 把提交阶段设计为同步不可打断，但它被精心切分为三个子阶段以控制单次阻塞时长：

Before Mutation 阶段：DOM 变更前，处理 getSnapshotBeforeUpdate 这类需要在 DOM 修改前读取快照的生命周期。Mutation 阶段：遍历副作用链，执行真实的 DOM 增删改，此阶段会同步卸载被删除组件的 componentWillUnmount、执行 ref 的解绑与重绑。Layout 阶段：DOM 已更新但浏览器尚未绘制，同步执行 componentDidMount、componentDidUpdate、useLayoutEffect 回调，此时读取布局信息（offsetWidth 等）是同步且准确的。而 useEffect 回调被安排为 Passive Effect，在绘制完成后的空闲时间异步执行——这就是 useEffect 与 useLayoutEffect 的本质区别。

这个设计带来一个微妙的权衡：Layout 阶段的所有同步回调仍然会阻塞绘制。因此 React 官方反复强调"能用 useEffect 就不要用 useLayoutEffect"——后者只应用于需要读取布局、在绘制前同步修改 DOM 的场景（如测量元素位置后放置 tooltip）。

六、React 18 并发特性实战

架构升级的最终目的，是把并发能力暴露给开发者。React 18 提供了三大核心 API。

6.1 startTransition：标记非紧急更新

import { startTransition, useDeferredValue, useState } from 'react';

function SearchBox() {
  const [inputValue, setInputValue] = useState('');
  const [query, setQuery] = useState('');

  function handleChange(e) {
    // 紧急更新：输入框必须立即响应
    setInputValue(e.target.value);
    // 非紧急更新：搜索结果列表可以延迟渲染
    startTransition(() => {
      setQuery(e.target.value);
    });
  }

  return (
    <>
      <input value={inputValue} onChange={handleChange} />
      <SearchResults query={query} />
    </>
  );
}

输入框的受控更新走 SyncLane，保证每一次按键都即时回显；而昂贵的搜索结果重渲染走 TransitionLane，一旦有更高优先级的输入进来就立即让路、丢弃旧的渲染结果。传统方案里这两种更新互相阻塞，要么输入卡顿要么结果滞后，Transition 则优雅地同时解决了两者。useDeferredValue 是同一思想的不同封装，适合无法修改状态更新调用处的场景。

6.2 Suspense 与流式 SSR

<Suspense fallback={<PostSkeleton />}>
  <PostDetail postId={postId} />
</Suspense>

Suspense 在并发架构下的语义是"这个子树的渲染依赖尚未就绪，可以先展示 fallback，数据到达后从中断处恢复渲染"。配合 React 18 的服务端渲染，renderToPipeableStream 支持流式输出 HTML、选择性注水（Selective Hydration），先交互先注水，长列表不再阻塞整页可交互时间。

6.3 useTransition 的 pending 状态

const [isPending, startTransition] = useTransition();
// isPending 为 true 期间可展示加载指示器，告知用户"正在计算"而非"卡死了"

七、React 19 的深化：Actions 与 useOptimistic

React 19 在并发模型之上进一步引入 Actions：将异步操作（表单提交等）与 Transition 机制整合。新的 useActionState 与 useOptimistic 允许在数据真正落库前就展示"乐观 UI"，请求失败时自动回滚：

function LikeButton({ postId }) {
  const [likes, submitLike, isPending] = useActionState(
    async (currentLikes, delta) => {
      const res = await api.like(postId, delta);
      return res.newCount;
    },
    initialLikes
  );
  return <button disabled={isPending}>👍 {likes}</button>;
}

这本质上仍是 Fiber 优先级模型的延伸：乐观更新的回滚与真实数据的覆盖，靠的正是不同 Lanes 之间的仲裁。

八、性能调优的工程建议

理解原理之后，落地到工程实践有几条高价值建议。第一，用 Profiler 定位而非凭直觉优化：React DevTools Profiler 的 Flamegraph 可以直观展示每个组件的渲染耗时与原因，90% 的"感觉卡"问题都源于某个列表组件在父组件每次状态变化时全量重渲染。第二，并发特性不等于免优化：Transition 只能缓解非紧急更新的阻塞，组件本身的开销（深拷贝、大数组排序放在 render 里）依然要治理，useMemo/useCallback/React.memo 应在测量确认后再使用，避免无谓的记忆化开销。第三，保持状态的最小化与就近原则：把频繁变化的 state 放到最深的公共父组件，配合 Zustand/Jotai 等原子化状态库按需订阅，从源头减少重渲染范围。第四，虚拟列表是大数据量场景的终极答案：React Window/TanStack Virtual 将数千条列表的 DOM 压缩到可视区几十个节点，比任何 Diff 优化都有效一个数量级。

九、总结

从 Stack Reconciler 到 Fiber，React 的演进史是一部"把同步计算改造为可调度协作"的教科书。Fiber 节点的链表结构与双缓冲机制解决了"可中断"的数据结构问题，Scheduler 与时间切片解决了"何时中断"的调度问题，Lanes 模型解决了"谁优先"的仲裁问题，而 Transition、Suspense、Actions 则把这套底层能力翻译成人话般的 API。对开发者而言，掌握这套心智模型的价值不仅在于写出更高性能的 React 应用，更在于理解现代 UI 框架在"响应性、一致性与性能"三角中的根本权衡——这套思想同样适用于 Vue 的调度器、Svelte 的编译时策略乃至浏览器的原生调度机制。