各位下午好，欢迎来到“React 并发模式：高速公路上的红绿灯艺术”研讨会。
我是你们今天的讲师。我知道，提到“React Lane 模型”或者“31 位掩码”这些词时，很多前端同学的第一反应是：“这玩意儿是不是在 React 内部源码里？是不是很深？我是不是得先去学学操作系统里的位运算才能看懂？”
别怕，今天我们不搞那些枯燥的教科书定义。我们要像剥洋葱一样，一层层剥开 React 的内核，看看那个 31 位的数字到底在后台里指挥着什么。我们将深入探讨它是如何通过数学上的“交集”来决定是否“批处理”，从而让我们的应用既流畅又高效。
准备好了吗？让我们把咖啡续上，开始这场深入骨髓的技术探险。
第一部分：位运算的哲学——为什么是“位”？
首先，我们要解决一个核心问题：为什么 React 要用位运算来管理任务？
想象一下，你是一个交通警察，站在一个繁忙的十字路口。你面前有 31 个车道，每个车道代表一种不同类型的交通需求：
- 第 0 号车道：紧急刹车，救护车来了。
- 第 1 号车道：用户正在疯狂点击按钮。
- 第 2 号车道：用户正在输入文字。
- 第 3 号车道：后台正在加载图片。
- …以此类推，直到第 31 号车道：用户刚关掉网页，浏览器决定休息一下。
在传统的 React（React 17 之前）里，这些任务就像是排队买票的人，谁先来谁先上，大家挤在一起。结果就是，如果用户疯狂点击按钮（高优先级），同时又有一个耗时的计算在后台（低优先级），那么这个耗时的计算会一直卡住用户点击的响应，导致界面“卡顿”。
为了解决这个问题，React 引入了 Lane（车道） 模型。这本质上就是 Bitmask（位掩码）。
在计算机科学里，一个 32 位的整数，每一位都是一个开关。开代表有车，关代表没车。
- 1 代表这个车道有任务。
- 0 代表这个车道空闲。
当 React 需要同时处理多个任务时，它不是把任务排成一个列表，而是把任务对应的“车道号”给“按位或”（OR）起来，生成一个新的 Mask（掩码）。
举个栗子：
假设现在有两个任务：
- 用户点击了按钮（第 5 号车道）。
- 页面正在接收数据（第 2 号车道）。
React 的调度器会计算：
Mask = (1 << 5) | (1 << 2)
二进制表示：0b00100000 | 0b00000100 = 0b00100100
这个 0b00100100 就是当前时刻的“任务掩码”。它像是一张地图，告诉调度器：“嘿，现在第 5 号和第 2 号车道都有车，其他车道都是空的。”
第二部分：交集——决定命运的数学
这是今天最核心的部分。当我们有两个不同的更新（比如一个来自用户点击，一个来自异步数据加载）同时到达时，调度器要做什么？它要判断这两个更新能不能一起跑。
这就涉及到了 Intersection（交集）。
在 React 的世界里，如果两个更新所在的“车道”没有重叠，它们就可以被合并在一起执行。如果它们重叠了，React 就得停下来，重新评估优先级。
1. 什么是“无交集”？
如果两个任务的掩码进行 &（按位与）运算，结果为 0，我们就说它们没有交集。
// 任务 A 在第 5 号车道
const laneA = 1 << 5; // 0b00100000
// 任务 B 在第 2 号车道
const laneB = 1 << 2; // 0b00000100
// 检查交集
const hasIntersection = (laneA & laneB) !== 0;
console.log(hasIntersection); // 输出: false结果： false。这意味着车道 A 和车道 B 是独立的。React 可以把这两个任务合并成一次渲染周期。这就是 Batching（批处理） 的基础。
2. 什么是“有交集”？
如果两个任务都在同一个车道，或者都在第 5 号和第 8 号车道（虽然这种情况较少见，除非优先级相同），那么它们就有交集。
// 任务 A 在第 5 号车道
const laneA = 1 << 5; // 0b00100000
// 任务 B 也在第 5 号车道（比如用户又点了一次）
const laneB = 1 << 5; // 0b00100000
// 检查交集
const hasIntersection = (laneA & laneB) !== 0;
console.log(hasIntersection); // 输出: true结果： true。这意味着第 5 号车道已经满了。React 不能简单地合并这两个更新，因为它必须确保最新的那个更新被执行。
第三部分：批处理的魔法——如何“偷”时间
现在，让我们进入最精彩的部分：自动批处理。
在 React 18 之前，setState 只能在事件处理函数（如 onClick）里生效。如果你在 setTimeout 或者 Promise.then 里调用 setState，React 会认为这是“外部”行为，会把它们拆成多次渲染。
但在 React 18 之后，引入了 requestEventPriority。这个函数就像是一个“间谍”，它会潜伏在代码深处，判断当前正在执行的任务是什么优先级。
场景模拟
假设我们在一个 setTimeout 里执行了两个 setState，同时页面正在渲染一个动画（第 30 号车道，高优先级）。
// 模拟 React 内部调度逻辑
let currentLane = 0; // 当前正在处理的 Lane
// 1. 动画帧触发，当前优先级提升到高优先级 (第 30 号车道)
currentLane = 1 << 30;
// 2. setTimeout 回调执行，里面有两个 setState
// React 内部捕获到这两个 setState 的优先级是普通优先级 (第 29 号车道)
const updateLane1 = 1 << 29;
const updateLane2 = 1 << 29;
// 3. 调度器检查：这两个更新和当前动画帧有交集吗？
const hasIntersection = (currentLane & updateLane1) !== 0;
console.log("动画帧与普通更新有交集吗？", hasIntersection); // true!
// 4. 判决
if (hasIntersection) {
console.log("警告：高优先级动画被打断！需要中断动画，先处理普通更新。");
// React 逻辑：中断当前渲染 -> 重新计算优先级 -> 重新开始渲染
} else {
console.log("好消息：可以合并！把这两个普通更新打包，等动画结束了一起渲染。");
// React 逻辑：合并更新 -> 推入队列 -> 等待调度
}这就是批处理的艺术： 当 Intersection 为 false 时，React 会悄悄地把这些更新“吞”掉，等到下一次渲染机会（比如动画帧结束）时，一次性把它们全部提交给 DOM。
第四部分：31 位掩码的深层映射——优先级的等级制度
为什么是 31 位？为什么不是 32 位？为什么不是 16 位？
因为 React 定义了 31 种优先级等级。这 31 个位，每一位对应一个优先级。数值越小，优先级越高（越紧急）。
让我们看看 React 源码中经典的 Scheduler 映射表（简化版）：
// Scheduler.js (简化概念)
export const NoPriority = 0;
export const ImmediatePriority = 1;
export const UserBlockingPriority = 31; // 最高的用户交互优先级
export const NormalPriority = 29;
export const LowPriority = 30; // 等等，这里数值越大优先级越低？
// 注意：在 Lane 模型中，1 << 0 是最高优先级，1 << 31 是最低优先级
// 所以：1 (Immediate) > 2 (UserBlocking) > ... > 1 << 31 (Idle)这里有一个反直觉的设计：
- Lane 0 (1 << 0) =
ImmediatePriority（最高，立即执行）。 - Lane 31 (1 << 31) =
IdlePriority（最低，浏览器空闲时才做）。
代码示例：Lane 的优先级计算
让我们写一个函数，把优先级数值转换成 Lane 掩码：
function getLaneFromPriority(priorityLevel) {
switch (priorityLevel) {
case 1: // Immediate
return 1 << 0;
case 2: // UserBlocking
return 1 << 1;
// ... 省略中间过程
case 29: // Normal
return 1 << 29;
case 30: // Low
return 1 << 30;
case 31: // Idle
return 1 << 31;
default:
return 0; // NoPriority
}
}为什么这么设计？
因为位运算极其高效。判断优先级不需要遍历数组，只需要看二进制的某一位是不是 1。
如果你有一个 Lane 掩码 0b00000000000000000000000000000001（只有 Lane 0 有任务），你一眼就能看出这是最高优先级的任务。如果你有 0b00000000000000000000000000000010（Lane 1），这是次高优先级。
第五部分：LaneToIndex 优化——为什么不用循环？
你可能会问：“如果我有 31 个 Lane，我每次都要去判断哪一位是 1 吗？那岂不是要循环 31 次？”
当然不是。React 还有一个绝招：LaneToIndex 映射。
它把“Lane 值”直接映射成了“索引”。这就像给每个车道装了一个 GPS 导航，你不需要数数哪一位是 1，你只需要查表，直接知道它是第几个车道。
// 这是一个巨大的数组，长度为 32（0-31）
// laneToLaneIndex[1 << 5] = 5
// laneToLaneIndex[1 << 2] = 2
const laneToLaneIndex = new Uint16Array(32);
// 初始化这个数组（伪代码）
for (let i = 0; i < 32; i++) {
laneToLaneIndex[1 << i] = i;
}实战应用：
假设我们有一个 Lane 掩码 currentLanes = 0b00100100（包含 Lane 2 和 Lane 5）。
朴素做法（慢）：
let highestLane = 0;
for (let i = 0; i < 32; i++) {
if (currentLanes & (1 << i)) {
highestLane = i; // 找到最高的位
}
}
// O(32) 次循环React 做法（快）：
// 1. 先找到最低位的 1 (LSB)，这代表最高优先级
// 0b00100100 的最低位是第 2 位 (Lane 2)
const lowestBit = currentLanes & -currentLanes;
// 0b00100100 & ~0b00100100 + 1 = 0b00000100
// 2. 查表得到索引
const highestPriorityLaneIndex = laneToLaneIndex[lowestBit];
// 3. 重新构造 Lane
const highestPriorityLane = 1 << highestPriorityLaneIndex;性能分析：
这种操作是 O(1) 的。React 每一帧都在做这件事，这种极致的优化保证了即使在手机这种性能受限的设备上，React 也能保持 60fps 的流畅度。
第六部分：深入“任务交集”——渲染的博弈
现在，让我们回到最关键的问题：任务交集如何决定 React 的渲染行为？
这涉及到 React 内部的一个核心函数：markRootUpdated。当组件调用 setState 时，React 会调用这个函数。
function markRootUpdated(root, updateLane) {
// 1. 将新的 Lane 加入到 Root 的总 Lane 集合中
root.pendingLanes |= updateLane;
// 2. 检查是否有交集
// 如果当前正在渲染的 lane 和新的更新 lane 有交集...
if (root.expiredLanes !== 0 || (root.entangledLanes !== 0)) {
// ... 需要重新调度渲染
ensureRootIsScheduled(root);
}
}案例：flushSync 的逆操作
React 默认会批处理。但有时候，你需要打破这个规则。这就是 flushSync 的由来。
import { flushSync } from 'react-dom';
function handleClick() {
// 1. 第一次更新：普通状态
setCount(c => c + 1);
// 2. 第二次更新：必须立即看到的结果
flushSync(() => {
setFlag(true);
});
// 3. 第三次更新：普通状态
setCount(c => c + 1);
}内部发生了什么？
setCount被调用。React 捕获到这是普通优先级（Lane 29）。flushSync被调用。React 知道这需要同步执行。它会强制提升优先级，将这次更新的 Lane 设置为ImmediatePriority(Lane 0)。- React 检查当前是否有正在进行的渲染。
- 如果有，且正在进行的渲染优先级低于
ImmediatePriority，React 会中断当前的渲染。 - 它会立即执行
flushSync里的代码，把 DOM 更新掉，然后再回来处理剩下的两个setCount。
为什么需要中断？
因为 flushSync 里是业务逻辑，不能被阻塞。如果 React 继续批处理，把后面两个 setCount 也混进去，flushSync 的结果可能就被覆盖了。Intersection（交集） 在这里起到了“刹车片”的作用：一旦发现高优先级任务介入，必须停止当前的一切。
第七部分：Lane 模型的演进——从 31 位到 32 位
我们一直提到 31 位，那第 32 位呢？
在 React 18 之前，Lane 模型通常使用 31 位（0-31）。但在 React 18 引入并发模式后，为了支持更复杂的调度需求（比如 Suspense 的超时和恢复），React 引入了 32 位 Lane。
多出来的那一位（第 32 位）通常用于 Shared Lane（共享 Lane）。
Shared Lane 是什么鬼？
想象一下，你有 100 个组件同时调用了 setState，但它们的优先级都是 NormalPriority。
- 如果不批处理，React 会渲染 100 次，性能爆炸。
- 如果全批处理，React 可能会一直渲染，导致动画卡顿。
Shared Lane 的作用：
它是一个“缓冲池”。React 会把这些 NormalPriority 的更新都扔到 Shared Lane 里。然后，调度器会在空闲时间（比如下一帧的空隙），或者当用户没有交互时，统一处理这些 Shared Lane 里的任务。
这就好比：平时大家排队，如果队伍太长，大家就先坐进休息区（Shared Lane），等有空位了再一个个进去（渲染）。
第八部分：实战演练——手写一个简易的 Lane 调度器
为了彻底搞懂，我们不妨抛开 React，自己写一个只有 4 位 Lane 的微型调度器。这能让你直观地看到交集和批处理是如何运作的。
class MiniScheduler {
constructor() {
this.currentLane = 0; // 当前正在处理的 Lane
this.queue = []; // 任务队列
}
// 添加任务
addTask(priorityLevel, task) {
// 1. 将优先级转换为 Lane (假设 1 是最高，4 是最低)
const lane = 1 << priorityLevel;
this.queue.push({ lane, task, priority: priorityLevel });
}
// 调度核心：找出最高优先级任务并执行
schedule() {
if (this.currentLane !== 0) return; // 如果已经在跑，就别乱插队了（除非是更高优先级）
// 2. 过滤出所有还在队列里的任务
const activeTasks = this.queue.filter(t => t.lane !== 0);
if (activeTasks.length === 0) return;
// 3. 找出最高优先级的 Lane (即最低数值的 Lane)
// 逻辑：找出 lane 值最小的那个
let highestPriorityLane = 31; // 初始化为最低优先级
activeTasks.forEach(t => {
if (t.priority < highestPriorityLane) {
highestPriorityLane = t.priority;
}
});
// 4. 执行任务
this.currentLane = 1 << highestPriorityLane;
console.log(`n--- 开始执行 Lane: ${highestPriorityLane} ---`);
const taskToRun = activeTasks.find(t => t.priority === highestPriorityLane);
if (taskToRun) {
taskToRun.task();
// 标记为已完成，从队列移除
taskToRun.lane = 0;
}
this.currentLane = 0;
console.log(`--- Lane: ${highestPriorityLane} 执行完毕 ---n`);
// 5. 递归调用，看看还有没有剩下的任务
this.schedule();
}
}
// --- 测试场景 ---
const scheduler = new MiniScheduler();
console.log("1. 用户点击了按钮 (Lane 1 - 紧急)");
scheduler.addTask(1, () => {
console.log("动作：处理紧急点击");
});
console.log("2. 同时，页面开始加载图片 (Lane 3 - 低优先级)");
scheduler.addTask(3, () => {
console.log("动作：加载图片...");
});
console.log("3. 此时，用户又点击了一次 (Lane 1 - 紧急)");
scheduler.addTask(1, () => {
console.log("动作：再次处理紧急点击");
});
console.log("4. 此时，用户输入了文字 (Lane 2 - 中等)");
scheduler.addTask(2, () => {
console.log("动作：处理输入");
});
// 运行调度器
scheduler.schedule();让我们预测一下输出：
1. 用户点击了按钮：加入队列。2. 同时，页面开始加载图片：加入队列。3. 此时，用户又点击了按钮：加入队列。4. 此时，用户输入了文字：加入队列。
执行过程：
- 第一轮： 调度器发现最高优先级是
Lane 1（紧急点击）。它执行第一个点击任务。 - 第二轮： 队列里还剩：图片加载、第二个点击、输入。最高优先级还是
Lane 1。它执行第二个点击任务。 - 第三轮： 队列里剩：图片加载、输入。最高优先级是
Lane 2（输入）。它执行输入任务。 - 第四轮： 队列里剩：图片加载。最高优先级是
Lane 3（图片）。它执行图片加载。
结果分析：
你可以看到，紧急任务（Lane 1）总是优先于普通任务（Lane 2）和低优先级任务（Lane 3）。这就是 Lane 模型通过优先级排序实现的。
如果我们要模拟“批处理”呢？
假设 React 检测到当前没有正在渲染的任务，它会把 Lane 1 和 Lane 2 合并：
mergedLane = (1 << 1) | (1 << 2) = 0b00000110
然后一次性执行这两个任务，而不是分四次执行。
第九部分：总结与展望
好了，同志们，我们的旅程即将结束。
我们今天穿越了 React 内部的迷雾，深入到了那个由 31 位掩码 构成的微观世界。
我们学到了什么？
- 位即车道： 每一位都是一个独立的优先级通道。
- 交集即裁决：
laneA & laneB决定了两个任务是“合并”还是“冲突”。 - 批处理即优化： 当交集为空时，React 不会傻傻地多次渲染 DOM，而是把更新打包，等到合适的时机（比如下一帧）一次性提交，极大提升了性能。
- 索引即魔法：
LaneToIndex技术让我们在常数时间内就能找到最高优先级的任务。
React 的 Lane 模型不仅仅是一堆位运算，它是一种资源管理哲学。它告诉计算机：在这个复杂的、充满了用户交互、网络请求和后台任务的宇宙里，资源是有限的。我们必须聪明地分配这些资源，确保最重要的任务（比如用户的点击）永远不被阻塞，而那些不那么重要的任务（比如图片加载）则要在空闲时悄悄进行。
当你下次在控制台里看到 render-lanes 相关的日志，或者在 React DevTools 的 Profiler 里看到绿色的“批量更新”标记时，希望你能会心一笑，因为你知道，在那背后，那 31 个二进制位正在为了你的应用流畅度而激烈地博弈。
这就是 React Lane 模型的深度。这不仅仅是代码，这是工程的艺术。
谢谢大家，下课！