🧭 React 理念：让时间屈服于 UI —— 从同步到可中断的演化之路

✍️ 作者：小dora | 一个在源码里"挖隧道"的前端工程师

一、开场：今天我们聊点"时间的事"

大家好，我是小dora。

今天咱们不讲API、不贴文档，而是聊聊 React 背后那件"看不见的事"------它是怎么让时间为UI服务的。

你可能听过 React 的官方理念：

React 是用 JavaScript 构建快速响应的大型 Web 应用程序的首选方式。

这句话看似朴素，但如果你真的深入源码，就会发现这里的"快速响应"不是一句营销口号，而是一套完整的时间哲学。

在我看来，React 做的事可以概括为一句话：

它在 JS 线程这个单线程的牢笼里，硬是"造"出了一个时间的多线程幻觉。

二、React 的敌人：CPU 与 IO

在我们写业务代码的时候，页面卡顿只有两种根本原因：

CPU 不够快 ------ JS 线程太忙，任务太多；
IO 不够快 ------ 数据还没回来，UI没法更新。

这两种情况对应着两个"时间的陷阱"：

CPU瓶颈：你做得太多。
IO瓶颈：你等得太久。

而 React 的伟大之处在于：

它用两套完全不同的机制，去解决这两种"时间焦虑"。

三、CPU瓶颈：当JS线程变成暴君

有一次我写了个小Demo：

javascript 复制代码

function App() {
  const len = 3000;
  return (
    <ul>
      {Array(len)
        .fill(0)
        .map((_, i) => (
          <li key={i}>{i}</li>
        ))}
    </ul>
  );
}
ReactDOM.render(<App />, document.querySelector("#root"));

结果页面像中了魔法一样------卡得一动不动。

我打开 Performance 面板一看：JS 执行了 73ms，

浏览器一帧才 16.6ms...... 这下好了，UI 线程彻底被"绑架"了。

要理解这个问题，我们得先知道一点浏览器机制：

JS 线程与 GUI 渲染线程是互斥的 。

也就是说，当 JS 执行时，浏览器不能绘制。

而浏览器 60Hz 的刷新率意味着：

每 16.6ms 必须完成 "JS 执行 → 布局 → 绘制"。

任何超过 16.6ms 的 JS 执行，都会造成掉帧。

在这种情况下，React 如果仍采用同步渲染模式（即一次性渲染整棵组件树），

那性能就只能听天由命。

于是 React 选择了革命性的道路------时间切片 (Time Slicing) 。

四、时间切片：JS 线程的"假并发革命"

React 17 之后引入了一个"黑科技"：

Concurrent Mode（并发模式）。

开启它只需一行：

scss 复制代码

ReactDOM.unstable_createRoot(rootEl).render(<App />);

这行代码的本质是启用 React 自己的"调度系统"------Scheduler。

从此，React 不再是"一个大任务"，而是一堆可以随时暂停、继续的小任务。

让我们先看看 Scheduler 的精髓伪代码：

ini 复制代码

function workLoop(deadline) {
  let shouldYield = false;

  while (nextUnitOfWork && !shouldYield) {
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
    shouldYield = deadline.timeRemaining() < 1;
  }

  requestIdleCallback(workLoop);
}

这里的关键在 deadline.timeRemaining()：

它告诉 React------浏览器这一帧还剩多少空闲时间。

于是 React 就像一位懂礼貌的客人：

"哦？你要刷新UI？那我先暂停，等你忙完我再继续渲染。"

这就是时间切片：

把一口吞不下的任务，拆成一口一口的小片。

而在底层，React 用的不是 setTimeout，

而是更精准的 MessageChannel + 宏任务调度 ，

甚至模拟了浏览器的帧节奏，自己在 JS 层维护了一套"任务调度循环"。

你可以把 Scheduler 想象成一个"用户态的微型操作系统"，

它为 React 任务分配"时间片"，并根据优先级做调度。

五、Fiber：React 的"虚拟堆栈帧系统"

要能中断任务，你得能"恢复任务"。

React 在这件事上干得极漂亮。

在 React 15 之前，渲染过程是递归调用：

scss 复制代码

function renderComponent(component) {
  renderComponent(component.child);
}

递归的问题是：一旦中断，调用栈就没了。

React 16 的 Fiber 架构，把递归改成了显式循环：

ini 复制代码

let nextUnitOfWork = rootFiber;
function performUnitOfWork(fiber) {
  // 处理逻辑
  reconcile(fiber);
  return fiber.child || fiber.sibling || fiber.parent?.sibling;
}

这看似平凡，却是架构级的飞跃。

现在，每个 Fiber 节点都像一个"虚拟的堆栈帧"，

保存了它的执行状态、上下文、优先级。

这意味着：

React 能暂停在任何一个 Fiber 节点，然后下一帧再从这里继续。

就像协程一样，React 在 JS 层实现了可恢复的堆栈帧模型。

这不是简单的"diff算法优化"，

而是一次从"栈式架构"到"链式调度"的结构性重写。

六、优先级调度：任务的"生死等级"

React Scheduler 不止能暂停任务，还能区分任务的重要程度。

来看这段源码（节选自 Scheduler.js）：

ini 复制代码

export const ImmediatePriority = 1;
export const UserBlockingPriority = 2;
export const NormalPriority = 3;
export const LowPriority = 4;
export const IdlePriority = 5;

它维护了一个基于**优先级堆（min heap）**的任务队列：

用户输入类任务 → 高优先级
后台更新类任务 → 低优先级

当高优先级任务出现时，低优先级任务会被中断，让出执行权。

没错，这和操作系统中的"抢占式调度"如出一辙。

React 在 JS 层模拟了一套 CPU 调度机制。

React 甚至定义了 shouldYield() 机制：

当当前帧的预算耗尽或有更高优先级任务出现时，主动 yield。

这就是 React 并发模式下"流畅响应"的秘密。

七、IO瓶颈：心理学驱动的"假延迟优化"

CPU 瓶颈是"算得太慢"，

IO 瓶颈则是"等得太久"。

网络延迟我们没法控制，但我们可以控制用户的感知。

你可以观察 iOS 的系统设置界面：

点击"通用"是立即切换；

点击"Siri 与搜索"其实要发请求，但体验几乎一样流畅。

为什么？

因为系统并不是立刻切换页面，

而是巧妙地"拖延"了几十毫秒，让人类的注意力刚好错开请求的等待。

React 的 Suspense 与 useDeferredValue 就是把这种人机交互策略引入前端框架。

xml 复制代码

<Suspense fallback={<Loading />}>
  <UserProfile />
</Suspense>

Suspense 并不是单纯地显示 Loading，

而是尝试"延迟显示"------

如果数据很快回来，就直接渲染，

只有在超过心理阈值时，才展示 fallback。

这不是性能优化，而是心理时间的欺骗。

React 在 IO 上用的是心理学，而不是算法。

八、结语：时间的哲学

在我研究 React 源码的这段时间里，最打动我的并不是 Fiber 的算法复杂度，

而是 React 团队对"时间"这件事的理解。

他们没有简单地让代码跑得更快，

而是让用户感知到它更快。

他们没有等待浏览器提供调度能力，

而是自己在 JS 层造了一个调度器。

这不只是框架层面的创新，

而是一次对"时间支配权"的重新夺回。

真正的快速响应，不是更快的计算，而是更聪明的等待。

------ 小dora

🔍 参考与延伸

React Fiber Architecture 设计文档
React Scheduler 源码路径：packages/scheduler/src/forks/Scheduler.js
卡颂老师《React 技术揭秘》
Dan Abramov《Inside Fiber: Incomplete Work》