为什么 React 页面依然卡顿？从主线程调度看本质在 React 的世界里，我们享受着组件化开发、声明式 UI、Hoo

在 React 的世界里，我们享受着组件化开发、声明式 UI、Hooks 的优雅设计。但当项目日益复杂，用户量暴增时，很多开发者会发现：明明用了 React 18，性能优化也做了，但页面依旧卡顿，交互不流畅，输入框有明显延迟。这到底是为什么？

这篇文章不谈虚拟 DOM 不谈 reconciliation，而是带你从浏览器底层的“主线程调度”角度，重新理解前端卡顿的根源。因为 React 再快，拯救不了被我们亲手堵死的主线程。

一、卡顿的真相：主线程被占满了

在浏览器里，JavaScript、样式计算、布局、绘制都发生在同一个线程——主线程。React 的渲染更新、事件响应、生命周期函数、DOM 操作，几乎也都发生在主线程中。

也就是说，如果主线程在执行一段 JS 代码时花了几百毫秒，用户的点击、输入、滚动等交互事件都会被延迟处理，形成我们肉眼可见的“卡顿”。

来看一个简单的例子：

function Blocker() {
  const handleClick = () => {
    const start = performance.now();
    while (performance.now() - start < 2000) {
      // 主线程被阻塞 2 秒
    }
    alert('任务完成');
  };

  return <button onClick={handleClick}>卡我两秒</button>;
}

点这个按钮页面直接卡住，不能滚动、不能输入、不能点击，因为主线程已经在 while 循环中无法响应其它任务。这类“同步卡顿”在 React 项目中非常常见，特别是在以下情况中：

JSON 数据解析太大
大量 DOM diff 和更新
多个 setState 连发
没有节流的 onChange/onScroll 监听

二、React 的调度机制：不是魔法

React 18 引入了 Concurrent 模式，的确增强了调度能力，但它依赖的是浏览器的 MessageChannel 和 requestIdleCallback 等机制，也就是说：

只要主线程是“空闲”的，React 才能插入自己的调度逻辑。否则，它什么也做不了。

React 的更新过程其实分为两个阶段：

Render Phase（可中断） ：构建新的 Fiber 树，执行 diff，准备更新（但还没动 DOM）
Commit Phase（不可中断） ：真正把变更应用到 DOM 上

即使是 React 18，在 render 阶段做了并发调度，也无法在主线程被阻塞时生效。如果你的代码中间执行了同步的大任务，那 render 阶段也会被推迟。

举个例子：

const onInput = (e) => {
  const val = e.target.value;
  startTransition(() => {
    setSearchQuery(val);
  });
};

这段代码使用了 startTransition 来告诉 React：“这是个低优先级任务”，但如果前面还有个 JSON.parse 卡了 500ms，这段代码依旧排不上用场。

三、常见的主线程陷阱

1. 批量 setState 引发的调度阻塞

for (let i = 0; i < 10000; i++) {
  setItems((prev) => [...prev, i]);
}

每个 setState 都会让 React 调度一次更新，即便批处理机制合并了它们，你依然在主线程上反复执行函数调用和数据合并操作。这种模式经常出现在从后端返回一个大列表时错误地 setState 多次。

正确方式是：一次性构造好数据，再 setState 一次。

2. 重计算、再渲染：渲染量爆炸

当组件数量达到几千，或者列表中每个 item 都有自己的子状态时，每一次父组件更新都会引发一次“重头开始”的渲染波及。

没用 React.memo 的子组件
每个组件都有复杂的 useEffect
不合理的 key 导致卸载重建

这些都会让 React 的渲染队列和 commit 阶段不断延长，甚至触发“掉帧”。

3. 用户交互优先级被抢占

React 虽然能分清哪些是“紧急任务”（如点击）哪些是“可延后任务”（如渲染），但如果我们滥用了状态更新，就可能让真正重要的交互被耽误。

startTransition(() => {
  setSearchResults(results); // 合理
});

setIsLoading(true); // 阻塞主线程的状态

建议：UI 控制类状态不要混进 Transition 里；用户输入响应保持同步更新。

四、解决之道：释放主线程压力

React 不慢，我们的写法慢。以下是一些推荐的优化方向：

✅ 使用 `startTransition` 分离低优先级任务

适用于搜索建议、异步加载、大量渲染等场景。

startTransition(() => {
  setFilteredList(expensiveFilter(data));
});

✅ Web Worker 搬运大计算

比如：JSON 解析、排序、大量合并数据，不要让主线程背锅。

// worker.js
self.onmessage = function (e) {
  const result = heavyComputation(e.data);
  self.postMessage(result);
};

在 React 里用 workerize-loader 或 comlink 都可以优雅封装。

✅ 虚拟列表，别渲染几千条

组件再快，也扛不住 5000 个 DOM 节点。react-window、react-virtualized 是长列表的标配。

✅ 节流 + 防抖：onScroll 和 onChange

const throttledScroll = useCallback(throttle(handleScroll, 100), []);

避免每 1ms 就触发一次 state 更新，让主线程喘口气。

✅ useMemo / React.memo 合理缓存

避免不必要的 diff 和重渲染，保持 render 阶段轻盈。

五、调试卡顿的武器库

别瞎猜，用工具。

Chrome DevTools → Performance 面板：查看主线程的 Timeline，找出哪段任务时间太长。
React DevTools → Profiler：找出谁在重复渲染，谁占用了最长时间。
why-did-you-render：开发阶段监测组件是否不该重新渲染。

这些工具可以精准定位“慢在哪”，而不是拍脑袋优化。

六、总结：不是 React 卡，是你太用力了

React 本身已经非常高效，尤其是 React 18 的并发架构。但它的执行环境依旧是浏览器主线程，如果我们不理解浏览器的执行机制，继续同步暴力 setState、大量无节制计算和渲染，那么 React 再聪明也拯救不了页面的卡顿。

记住：不是 React 卡，是你不给它喘息的机会。

优化性能的第一步，从尊重主线程的节奏开始。

为什么 React 页面依然卡顿？从主线程调度看本质