欢迎来到 CPU 的“午休时间”：React 并发渲染任务抢占机制深度剖析
各位同学，大家好！
欢迎来到今天的讲座，主题是《React 并发渲染任务抢占机制实现》。我是你们今天的讲师，一个在浏览器主线程里和 CPU 赛跑多年的资深搬砖工。
咱们今天不讲那些虚头巴脑的概念，也不背八股文。咱们要聊的是 React 16 之后那个让无数前端工程师既爱又恨的“并发模式”。简单来说，就是 React 终于学会了“见好就收”，学会了在 CPU 忙不过来的时候，把活儿停下，喘口气，然后再继续干。
如果你们觉得 React 只是换个库，那你们就太小看 React 团队的技术野心了。React 并发模式本质上是在浏览器的主线程上，硬生生地搞出了一个时间切片和优先级队列的微操作系统。
来，坐稳了，咱们开始。
第一部分：主线程的“独裁统治”与 React 的“阻塞危机”
首先，咱们得聊聊浏览器是怎么工作的。浏览器是单线程的，这就好比一个只有一张办公桌的老板。所有的任务——无论是解析 HTML、执行 JavaScript、绘制页面，还是响应用户的点击，都得排队，一个接一个地来。
以前，React 是个“死脑筋”。如果你给 React 一个包含 10,000 个列表项的列表，它就像个只会蛮干的傻大个，从第一个开始渲染，一直渲染到第 10,000 个。在这个过程中，浏览器的 UI 就会完全卡死。你点击按钮，页面没反应；你滚动页面，页面像被胶水粘住了一样。
这就叫阻塞渲染。CPU 被 React 完全占用了，没有时间去处理其他高优先级的任务，比如你的鼠标悬停、键盘输入。
React 团队意识到：“CPU 是我的，但也是浏览器的。我不能把它榨干，我得学会偷懒。”
于是，并发模式诞生了。它的核心思想就是：把一个大任务切成无数个小任务，每做完一小会儿，就主动让出控制权给浏览器，让浏览器去处理用户输入、绘制页面。等浏览器忙完了，我再回来继续干活。
第二部分：Fiber 架构——把“树”变成“链表”
怎么切任务？React 需要一个能被打断、能暂停、能恢复的数据结构。以前的虚拟 DOM 是一棵树，树是递归的，很难中断。于是，React 引入了 Fiber。
别被名字骗了，Fiber 不是什么高科技纤维材料，它是一个任务节点。React 把整个组件树，从一棵树，变成了一条链表。
每一个组件都是一个 Fiber 节点。这个节点里存了组件的 stateNode（真实 DOM）、child（子节点）、sibling（兄弟节点）。
// 这是一个极简的 Fiber 节点结构示例
function FiberNode() {
this.tag = 0; // 标记类型：函数组件、类组件、HostComponent 等
this.pendingProps = null; // 待处理的属性
this.memoizedProps = null; // 缓存的属性
this.updateQueue = null; // 更新队列
this.stateNode = null; // 真实的 DOM 节点
// 核心中的核心：链表结构
this.return = null; // 父节点
this.child = null; // 第一个子节点
this.sibling = null; // 下一个兄弟节点
}通过 Fiber，React 不再是一次性遍历整个树，而是变成了链表的遍历。链表的特点就是，指针指到哪里，我就算到哪里。如果我要中断，我只需要把当前指针保存起来，下次再来的时候，从指针开始继续往下走就行了。
第三部分：Scheduler——React 的“调度员”
光有 Fiber 节点还不够，还得有个调度员来发号施令。这个调度员就是 Scheduler 模块。
Scheduler 的任务就是决定：什么时候该干活？什么时候该休息？
在浏览器中，有几个关键的 API 可以帮助我们控制 CPU 的使用权：
requestAnimationFrame(RAF)：告诉浏览器，“嘿，下一帧动画开始前，请调用我”。这是高优先级的，通常用于动画和滚动。requestIdleCallback(RIC)：告诉浏览器，“我没事了，如果你也闲着，就让我干点轻活吧”。这是低优先级的，用于后台计算。setTimeout(宏任务)：虽然也是异步，但通常用于兜底。
React 的 Scheduler 做了一个非常精妙的封装。它不是简单粗暴地调用这些 API，而是基于时间切片的算法。
时间切片原理：
假设我们要渲染一个巨大的列表。Scheduler 会给当前渲染任务分配一个时间预算（比如 5 毫秒）。
- React 开始执行渲染，执行 5 毫秒。
- 5 毫秒到了，Scheduler 说：“时间到，我要休息了！”
- React 暂停渲染，把当前进度（Fiber 树的指针）存起来。
- 浏览器此时可以处理用户的点击、滚动，界面立刻变得流畅。
- 等浏览器处理完高优先级任务，发现空闲了，调用
requestIdleCallback。 - React 再次被唤醒，从上次暂停的地方继续渲染。
第四部分：任务抢占机制——高优先级任务的“插队权”
这是并发模式最迷人，也最复杂的地方。
假设你现在正在渲染一个巨大的列表（低优先级任务）。突然，用户点击了“提交”按钮（高优先级任务）。
在非并发模式下，React 会等列表渲染完，再处理点击事件。但在并发模式下，高优先级任务可以“插队”。
React 的调度器维护了一个优先级队列。每个任务都有一个优先级。
代码演示：模拟一个简单的抢占式调度器
为了让大家看懂，咱们手写一个简化版的调度器逻辑：
// 定义任务优先级
const Priority = {
Immediate: 4, // 最高：点击、输入
UserBlocking: 3, // 中高：悬停
Normal: 2, // 普通：数据加载
Low: 1, // 最低：后台渲染
Idle: 0 // 极低：空闲时才做
};
class MiniScheduler {
constructor() {
this.taskQueue = []; // 任务队列
this.currentTask = null;
this.isRunning = false;
}
// 添加任务
schedule(task, priorityLevel) {
this.taskQueue.push({ task, priorityLevel });
// 排序：优先级高的在前面
this.taskQueue.sort((a, b) => b.priorityLevel - a.priorityLevel);
if (!this.isRunning) {
this.isRunning = true;
this.next();
}
}
// 下一个任务
next() {
if (this.taskQueue.length === 0) {
this.isRunning = false;
console.log("CPU 空闲了，去喝杯咖啡吧");
return;
}
// 取出优先级最高的任务
const { task } = this.taskQueue.shift();
this.currentTask = task;
console.log(`开始执行任务: ${task.name}，优先级: ${task.priorityLevel}`);
// 模拟时间切片：执行 2 毫秒
setTimeout(() => {
console.log(`任务 ${task.name} 执行完毕`);
// 关键点来了：抢占检查
// 如果队列里来了一个更紧急的任务（比如用户点击），我们需要重新排序
// 简单起见，这里我们假设每次执行完都检查一下是否有新任务插入
// 在 React 中，这个检查是实时的
this.next();
}, 2);
}
}
// 使用场景
const scheduler = new MiniScheduler();
// 1. 用户正在看列表（低优先级）
scheduler.schedule({ name: "渲染列表项 1", priorityLevel: Priority.Low }, Priority.Low);
scheduler.schedule({ name: "渲染列表项 2", priorityLevel: Priority.Low }, Priority.Low);
// 2. 紧接着，用户点击了按钮（高优先级）
// React 会立刻把这个任务扔进队列，并触发重新调度
setTimeout(() => {
console.log("检测到用户点击！");
scheduler.schedule({ name: "处理点击事件", priorityLevel: Priority.Immediate }, Priority.Immediate);
}, 1); // 在第一个任务开始后 1 毫秒插入在这个例子中，虽然“渲染列表项 1”先开始，但“处理点击事件”因为优先级更高，被插到了队首，并优先执行。这就是抢占机制。
第五部分：React 内部实现细节——从源码看“时间切片”
React 源码中的 Scheduler 模块其实非常硬核。它不仅仅是一个队列，它是一个基于过期时间和优先级的复杂算法。
1. 优先级的计算
React 定义了几种优先级：
ImmediatePriority(Immediate)UserBlockingPriority(User Blocking)NormalPriority(Normal)LowPriority(Low)IdlePriority(Idle)
React 会在渲染过程中动态计算优先级。比如，如果一个组件正在渲染，而父组件收到了一个紧急更新，那么子组件的渲染优先级会自动提升。
2. requestIdleCallback 的兼容性坑
React 为了兼容性，自己实现了一套 requestIdleCallback 的 polyfill。因为不是所有浏览器都支持这个 API。
React 会根据当前时间计算剩余时间。如果剩余时间不足以完成当前任务的 5ms 预算，它就会强制让出控制权，把当前任务“挂起”，等到下一帧的 requestIdleCallback 再回来。
3. 工作循环
React 的核心循环是这样的：
function workLoop() {
// 只要还有任务，且时间还没用完
while (nextUnitOfWork && !shouldYield()) {
// 执行任务：创建 DOM、更新 DOM
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
}
// 如果任务没做完，且应该让出控制权
if (nextUnitOfWork) {
scheduleCallback(IdleCallbackPriority, workLoop);
} else {
// 任务完成，提交阶段
commitRoot();
}
}这里的 shouldYield() 函数就是判断时间是否到了的开关。如果到了，它就返回 true，React 就会跳出循环，把控制权交给浏览器。
第六部分：中断的副作用与 flushSync
既然任务可以被中断，那副作用怎么办？useEffect 是同步执行的，如果渲染被中断了，useEffect 会不会被跳过？
答案是：不会跳过。
React 会保证在渲染完成（无论中间被打断多少次）之后，执行所有的 useEffect。
但是，有一个特殊情况。如果你在 useEffect 里直接调用了 setState，这会触发一个新的渲染。如果这个新的渲染优先级很高，它可能会再次打断当前正在进行的渲染。
为了防止这种混乱，React 提供了 flushSync。
flushSync 的作用是强制将更新同步执行，并立即提交到 DOM。它会把 React 的并发特性“冻结”在这一刻。
import { flushSync } from 'react-dom';
function handleClick() {
// 强制同步更新 state
flushSync(() => {
setCount(count + 1);
});
// 此时 DOM 已经更新了，React 会立即处理下面的代码
// 即使这会导致一次新的渲染，它也会等待上面的 flushSync 完成
setFlag(true);
}第七部分：useTransition —— 并发模式的 API
讲了这么多底层原理，React 也给我们提供了上层的 API 来使用这个机制。最核心的就是 useTransition。
useTransition 允许你告诉 React：“嘿，这个更新是低优先级的，别阻塞用户的主要操作。”
代码示例
import { useState, useTransition } from 'react';
export default function SearchPage() {
const [query, setQuery] = useState('');
const [isPending, startTransition] = useTransition();
const [list, setList] = useState([]);
const handleChange = (e) => {
const value = e.target.value;
setQuery(value); // 1. 立即更新输入框（高优先级）
// 2. 使用 startTransition 包裹低优先级更新
startTransition(() => {
// 这里的逻辑会比较耗时，比如根据输入搜索 10 万条数据
const filtered = bigDatabase.filter(item => item.includes(value));
setList(filtered); // 3. 更新列表（低优先级）
});
};
return (
<div>
<input value={query} onChange={handleChange} />
{/* isPending 为 true 时，显示 Loading，或者让列表渲染慢一点 */}
{isPending ? 'Loading...' : list.map(item => <div key={item}>{item}</div>)}
</div>
);
}在这个例子中：
- 用户输入字符，
setQuery立即执行。界面上的输入框会立刻响应，没有任何延迟。这是高优先级。 startTransition把后面的搜索逻辑包裹起来。React 会把这个任务放入低优先级队列。- 当用户在输入框打字时，React 不会去渲染那 10 万条数据的列表。它会优先保证输入框的流畅。
只有当用户停止打字，或者输入框不再需要高频更新时，React 才会“抽空”去渲染列表。
第八部分：useDeferredValue —— 简化版的列表延迟
除了 useTransition，还有一个 API 叫 useDeferredValue。它和 useTransition 配合使用。
它的作用是：当你有一个值变化很快，但你希望渲染慢一点的时候，把它传给 useDeferredValue。
function Page() {
const [count, setCount] = useState(0);
// 延迟值
const deferredCount = useDeferredValue(count);
return (
<>
<button onClick={() => setCount(c => c + 1)}>Increment</button>
<Suspense fallback={<div>Loading...</div>}>
<ExpensiveList count={deferredCount} />
</Suspense>
</>
);
}当 count 变化时，deferredCount 不会立即更新。React 会等待，直到当前的渲染（ExpensiveList）完成，或者浏览器空闲了，再更新 deferredCount。这通常用于处理列表过滤时的闪烁问题。
第九部分：深度解析——为什么这么难？
很多人可能会问：“我有 5000 个列表项，直接 React.memo 或者 React.lazy 加载不就行了？为什么要搞这么复杂的并发渲染？”
这里有几个深层原因：
- 混合更新：并发渲染允许你同时进行多个更新。比如，你在等待一个网络请求，同时用户在疯狂点击按钮。React 可以同时处理这两个任务，而不是傻傻地排队等请求回来。
- 错误边界：在时间切片中，如果渲染某个组件抛出了错误，React 可以捕获这个错误，只卸载报错的组件，而不是导致整个应用崩溃。
- 性能优化：对于复杂的 UI，并发渲染可以避免“卡顿感”。虽然总渲染时间可能没变，但用户的感知性能变好了，因为界面在交互时不会卡死。
第十部分：实战中的陷阱与最佳实践
虽然并发模式很强大，但用不好就是灾难。这里有几个“坑”：
1. 不要滥用 startTransition
如果你只是渲染一个简单的按钮状态，用 useTransition 反而会增加开销。只有当渲染逻辑确实很重（比如大数据列表、复杂计算、复杂动画）时才用。
2. 避免在 useEffect 里做耗时的同步操作
如果在 useEffect 里 fetch 数据，这会阻塞渲染。你应该在渲染阶段做数据获取，或者使用 Suspense。
3. 理解 isPending
useTransition 返回的 isPending 是用来指示“这个低优先级任务是否正在进行中”。你可以用它来显示一个“正在思考”的图标，给用户一种正在处理的感觉。
结语：CPU 也是要休息的
讲了这么多，React 并发渲染的本质其实就是对 CPU 时间的精细化管理。
以前，React 是个“强迫症”，不把活干完绝不罢休，哪怕累死主线程。现在，React 学会了“太极拳”，它懂得四两拨千斤，懂得在关键时候（用户交互）把力量用出来，在空闲时候（浏览器处理其他任务）积蓄力量。
这就是抢占式调度的精髓：在合适的时间，做合适的事。
希望今天的讲座能让大家对 React 的并发渲染机制有一个清晰的认识。下次当你看到那个流畅的输入框，或者那个不卡顿的列表时，记得，那背后是成千上万次微小的“抢占”和“让步”。
下课！大家有问题可以举手（在评论区提问），咱们下期见！