React 任务抢占逻辑：分析高优先级 Lane 如何通过 throw 机制强制中断当前的 workLoop 迭代

各位听众，大家下午好。

请把你们的笔记本电脑合上，把手机屏幕朝下扣在桌子上。现在，我们进入一个纯理论的、极其硬核的、甚至有点折磨人的世界——React 的并发渲染世界。

我知道，你们在写代码时，React 总是那么“听话”，组件一变，界面就跟着变。但你们有没有想过，当你在写一个几百行的大组件，屏幕上疯狂闪烁着加载动画，突然你按了一下 Tab 键或者点击了一个按钮，那个加载动画瞬间消失，按钮立马就响应了？这背后发生了什么？

这就像是一个魔术。魔术师（React）在台前表演，而你们（浏览器）在后台疯狂地搬运砖头（执行 JS）。如果魔术师只顾着表演，而不管后台的砖头堆得像喜马拉雅山一样高，那浏览器早就崩溃了。

所以，React 引入了“并发”。并发是什么？就是“你先做那个不急的，我这边有急事，我先插队”。

而今天，我们要聊的就是这个“插队”的核心——Lane（车道/优先级），以及那个最狠辣、最直接、最“不优雅”的机制——Throw（抛出中断）。

准备好了吗？我们要开始扒开 React 的裤衩，看看它的内裤是怎么绑鞋带的。

---

第一部分：Lane 的世界——优先级的位图艺术

首先，我们得理解 Lane。在 React 18 之前，我们谈的是 Priority，比如 highPriority，lowPriority。这太模糊了。就像你去餐厅点菜，你说“给我来个急的”，厨师怎么知道你是想喝汤快一点，还是想煎牛排快一点？

于是，React 引入了 Lane。Lane 是什么？它是优先级的位图。

想象一下，你有 32 个位（32-bit），你可以把每一位都看作一个独立的“车道”。有的车道是高速公路，有的车道是乡间小路。

• Sync Lane (同步车道)：这是最快的。谁在用？用户点击按钮、输入框打字。这是“必须马上处理，否则用户会以为死机了”的优先级。
• Input Continuous Lane：鼠标拖动、滚动。这是“跟手”的优先级。
• Default Lane：这是“随便什么时候做都行”的优先级。比如点击 Tab 切换标签页，或者某些非关键的副作用。
• Idle Lane：这是“垃圾回收时间”。当用户没在操作的时候，React 在后台悄悄清理内存。

为什么用位图？因为位图运算极快。要判断“我有高优先级任务吗？”，不需要遍历数组，只需要做一个 & 运算（按位与）。如果结果不为 0，说明有。

代码示例：Lane 的定义与优先级判断

// 模拟 Lane 定义
const NoLane = 0b0000;
const SyncLane = 0b0001;
const InputContinuousLane = 0b0010;
const DefaultLane = 0b0100;
const IdleLane = 0b1000;

// 我们可以组合 Lane
const SomeHighPriorityLanes = SyncLane | InputContinuousLane;

function hasPriority(lane, priority) {
  return (lane & priority) !== 0;
}

// 场景：用户正在输入（InputContinuousLane），同时后台有一个低优先级的任务在跑（DefaultLane）
const currentLane = InputContinuousLane;
const backgroundTaskLane = DefaultLane;

console.log("用户输入时，背景任务是否需要被中断？", hasPriority(currentLane, backgroundTaskLane)); 
// 输出: false (这是错的，因为背景任务优先级低，输入优先级高，应该中断)

// 正确的逻辑应该是：背景任务是否被当前的高优先级 Lane 覆盖？
// React 的逻辑是：如果当前正在处理的 Lane 不是 Idle，那么 Idle 优先级的任务就被阻塞了
function isIdleLaneBlocked(currentLane, idleLane) {
  return (currentLane & idleLane) !== 0;
}

console.log("输入打断 Idle 任务？", isIdleLaneBlocked(currentLane, IdleLane)); 
// 输出: true (这就是答案！输入的 Lane 和 Idle 的 Lane 做了与运算，结果非零，说明 Idle 被阻塞了)

看懂了吗？Lane 就是这样一个基于位运算的“看门人”。它决定了谁有资格进入“渲染室”。

---

第二部分：调度器——那个爱发脾气的监工

Lane 只是数据结构，谁来决定什么时候切换 Lane？是 Scheduler（调度器）。

Scheduler 是 React 的心脏。它就像一个极其苛刻的监工，手里拿着秒表。它知道浏览器什么时候能腾出手来（requestIdleCallback 或 requestAnimationFrame），也知道什么时候必须马上干活（setTimeout 或直接调用）。

当 Scheduler 决定开始渲染时，它会启动一个 Work Loop（工作循环）。这个循环会不断地调用你写的组件函数，生成 Fiber 树。

Work Loop 的本质是什么？
它就是一个 while 循环。

function workLoop() {
  while (nextUnitOfWork !== null) {
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }
}

这个循环看起来很温顺，对吧？它一直在跑，跑得比浏览器的主线程还快。但是，这个循环有一个致命的弱点：它是单线程的，而且是阻塞的。

如果我在 performUnitOfWork 里写了一个 while(true) 死循环，整个浏览器就卡死了。

所以，React 必须在这个循环里埋下定时器，或者监听事件。一旦检测到高优先级任务来了，它必须立刻停下手里的活。

---

第三部分：冲突时刻——当“大妈跳广场舞”遇上“救火队”

现在，我们进入最精彩的场景。

假设，我们的应用里有一个侧边栏组件 Sidebar，它正在执行一次低优先级的渲染。这就像一个大妈在跳广场舞，节奏很慢，动作很舒展。

与此同时，用户突然点击了页面顶部的“保存”按钮。这是一个 Sync Lane（同步车道） 任务。这是“消防队”来了！他们必须马上冲进去，把火扑灭。

这时候，React 的调度器（Scheduler）发现了这个紧急任务。它的脑子里闪过一句话：“哦豁，SyncLane 任务来了，这可是要命的，不能等了。”

于是，调度器做了一个决定：中断当前的低优先级任务。

但是，怎么中断？你不能直接在 while 循环里写 break，然后说“我不干了”。因为 Sidebar 的渲染已经进行了一半，它的 Fiber 节点已经生成了一部分。如果直接扔掉，下次再渲染 Sidebar 时，又要从头开始，那是极大的浪费。

React 的解决方案非常粗暴，也非常优雅：Throw（抛出中断）。

第四部分：Throw 机制——最狠辣的“抛硬币”中断法

在 React 的内部实现中，workLoop 并不是在一个普通的 try-catch 块里运行的（虽然它确实有 try-catch，但那是处理用户代码报错的）。

当 Scheduler 决定要中断时，它会抛出一个特殊的错误对象。

这个错误对象通常被称为 InterruptedLaneError 或者类似的代号。它的内部属性记录了被中断的 Lane。

代码示例：模拟 Throw 机制

// 1. 定义中断错误对象
class InterruptedLaneError extends Error {
  constructor(lane) {
    super('Render was interrupted by a higher priority update');
    this.lane = lane; // 记录是谁抢了我的活
    this.name = 'InterruptedLaneError';
  }
}

// 2. 模拟 Work Loop
function workLoop(lanes) {
  // 我们把整个渲染逻辑包裹在一个 try 块里
  try {
    let nextUnitOfWork = root.current;

    while (nextUnitOfWork !== null) {
      // 执行工作单元
      nextUnitOfWork = performUnitOfWork(nextUnitOfWork);

      // 检查是否有更高优先级的任务插队
      // 这里的 checkForPriorityUpdates 是 Scheduler 的魔法时刻
      const currentLane = getNextLane(); 

      if (isHigherPriority(currentLane, lanes)) {
        // 关键时刻到了！
        // 抛出一个错误！
        throw new InterruptedLaneError(currentLane);
      }
    }
  } catch (error) {
    // 3. 捕获中断
    if (error instanceof InterruptedLaneError) {
      // 确认是中断错误，而不是组件里的 bug
      console.log(`哎呀，被 Lane ${error.lane} 抢走了！`);

      // 我们不能直接 return，因为那样函数就结束了
      // 我们需要把控制权交还给 React 的调度逻辑
      // React 会根据 error.lane 重新计算任务
      return { interrupted: true, lane: error.lane };
    } else {
      // 如果是真正的组件报错，那是另外一回事了（这里简单处理）
      throw error;
    }
  }
}

这就是 Throw 机制 的核心。

为什么用 Throw？

1. 强制中断：在 JavaScript 中，throw 是唯一能跳出深层嵌套循环（比如递归遍历 Fiber 树）而不需要层层 return 的方法。如果用 return，你需要修改 performUnitOfWork 的签名，把中断状态传出去，代码会变得极其丑陋。
2. 异常处理：利用 JS 的错误处理机制，我们可以很方便地把“正常流程”和“中断流程”隔离开来。中断就是一种“异常”状态。

---

第五部分：中断后的处理——垃圾回收的艺术

这里有一个非常高级的概念，叫做 垃圾回收。

当 workLoop 被 throw 打断时，它并没有把已经生成的 Fiber 节点扔掉。React 非常聪明，它把已经完成的部分（Completed Work）保留了下来，挂在一个列表上。

场景推演：

1. 初始状态：FiberRoot 指向 HostRoot。
2. 低优先级渲染：React 开始渲染 Sidebar。
   • 它生成了 HostRoot -> Body -> Sidebar -> Item。
   • 它把 Item 标记为“已完成”，并挂到了 FiberRoot 的 completedEffects 链表上。
3. 中断发生：用户点击了“保存”按钮。
   • workLoop 抛出 InterruptedLaneError。
   • 当前正在构建的 Sidebar 节点（以及它下面的子节点）被丢弃。
4. 高优先级渲染：
   • React 捕获到错误，拿到高优先级 Lane。
   • 它再次调用 renderRoot。
   • 它检查 FiberRoot。它发现 Item 已经在 completedEffects 里面了！
   • React 做了一个极其关键的判断：如果新渲染的节点已经在 completedEffects 里面了，那就跳过它！直接复用！

这就是为什么 React 18 在切换优先级时不会导致页面闪烁或重绘。因为已经画好的部分，React 知道它在哪里，它不需要再画一遍。

代码示例：垃圾回收逻辑

function renderRoot(root, lane) {
  // 初始化 WorkInProgress 树（正在构建的树）
  let workInProgress = root.current;
  let subtreeHasLanes = false;

  // 重新开始循环
  while (workInProgress !== null) {
    // ... 执行工作单元 ...
    // 假设我们刚刚处理完 Sidebar 的一个 Item

    // 检查这个节点是否已经在“已完成列表”里了？
    // 这是一个极其昂贵的检查，但 React 使用了位图优化
    const completedLane = getCompletedLane(workInProgress);

    if (lane === completedLane) {
      // 哦，这玩意儿我刚才画过了！
      // 跳过！直接指向它的子节点
      workInProgress = workInProgress.child;
      continue;
    }

    // 如果没画过，那就继续画
    workInProgress = performUnitOfWork(workInProgress);
  }
}

这就像你正在画一幅巨大的油画，画到一半被老师叫停了。你把画笔一扔。老师让你去画黑板报（高优先级任务）。

你画完黑板报回来，发现油画已经画了一半。你不需要把画布撕了重来，你只需要记住你刚才画了哪一块，下次画的时候，跳过那块，接着画剩下的。

---

第六部分：深入 Scheduler——抢占的源头

我们刚才说了 workLoop 里的 throw，但 throw 是谁触发的？是 Scheduler。

在 React 18 中，Scheduler 是一个独立的包（scheduler 包）。它管理着所有的任务队列。

当 Scheduler 收到一个新的任务（比如用户的点击），它会计算这个任务的 Lane（比如 SyncLane）。

然后，它会对比当前正在运行的任务的 Lane（比如 IdleLane）。

如果新任务的 Lane 优先级 更高（比如 SyncLane > IdleLane），Scheduler 会做两件事：

1. 标记中断：它会在内部状态中设置一个 didUserCallbackTimeout 或者类似的标志，告诉 React “有更重要的活来了”。
2. 抛出中断：在 React 的实现中，这通常表现为 Scheduler 抛出一个 timeout 事件，或者 React 在 workLoop 中检测到一个 shouldYield 的信号。

Scheduler 的伪代码：

function scheduleCallback(lane) {
  const newTask = {
    lane: lane,
    startTime: getCurrentTime()
  };

  // 把新任务塞进队列
  taskQueue.push(newTask);

  // 排序队列，Lane 越小（数字越小，优先级越高）越靠前
  taskQueue.sort((a, b) => a.lane - b.lane);

  // 如果当前没有正在运行的任务，或者新任务的优先级高于当前任务
  if (!isRunning || newTask.lane < currentRunningTask.lane) {
    // 赶紧启动！
    requestHostCallback(runWorkLoop);
  }
}

function runWorkLoop() {
  const startTime = getCurrentTime();

  while (tasks.length > 0) {
    const task = tasks[0];

    // 检查时间片是否用完
    if (getCurrentTime() - startTime > frameDeadline) {
      // 时间到，让出控制权给浏览器
      requestHostCallback(runWorkLoop);
      return;
    }

    // 检查是否有更高优先级的任务在排队
    const nextTask = tasks[1];
    if (nextTask && nextTask.lane < task.lane) {
      // 发现有人插队了！
      // 告诉 React 的渲染器：“嘿，别画了，有急事！”
      throw new InterruptedLaneError(nextTask.lane);
    }

    // 执行当前任务
    task.callback();
    tasks.shift();
  }
}

这就像是一个抢椅子游戏。音乐一停（高优先级任务来了），大家都要立刻停下手里的动作，去抢那个新的椅子。如果轮到你正坐在椅子上，突然发现椅子被别人抢了，你就得站起来，让给别人。

---

第七部分：递归与中断的博弈

React 的 Fiber 树是递归遍历的。performUnitOfWork 调用 beginWork，beginWork 又调用 beginWork。

这意味着，中断可能发生在任何深度。

假设我们有一个巨大的组件树：
App -> Header -> Nav -> Sidebar -> Item -> Content

如果中断发生在 Content 这一层，那么 Sidebar 之前的所有节点（App, Header, Nav, Sidebar）都已经完成了。它们会被标记为 completed。

而 Item 和 Content 没完成，被丢弃了。

下次渲染时，React 会从 App 开始。它发现 App 是 completed 的，跳过。Header 是 completed 的，跳过。Nav 是 completed 的，跳过。Sidebar 是 completed 的，跳过。

然后它到了 Sidebar 的子节点 Item。它发现 Item 没有被标记为 completed（因为上次被中断了），于是它重新调用 beginWork。

这就是 垃圾回收 的威力。它保证了即使任务被频繁打断，React 也不会因为重复计算而变慢。

---

第八部分：实战中的陷阱——Throw 并不是万能的

虽然 throw 机制很酷，但它也有代价。

1. 异常堆栈污染：频繁的 throw 会导致 JS 引擎的异常堆栈变长。如果用户在控制台报错，可能会看到一大串“Render was interrupted…”。React 虽然捕获了它，但这个过程对引擎来说是有开销的。
2. 内存开销：虽然 React 做了垃圾回收，但在极端情况下（疯狂点击），WorkInProgress 树和 Completed 树同时存在，内存消耗会显著增加。
3. 调试困难：对于开发者来说，打断点很难。因为代码在 try-catch 块里跳来跳去，你很难确定代码到底是在“正常执行”还是“被中断了”。

但是，相比于“浏览器卡死”或者“用户体验极差”，这些代价都是值得的。

---

第九部分：总结——优雅的混乱

让我们把镜头拉远，看看 React 的并发渲染全景图。

Lane 决定了任务的生死。
Scheduler 决定了任务的顺序。
而 Throw 机制，则是那个在混乱中维持秩序的暴君。

它通过抛出一个错误，强制中断了正在进行的递归渲染。它利用 JS 的异常处理机制，将“中断”这个逻辑行为变成了“异常处理”的流程。

这就像是一个指挥家（React），在乐队演奏到一半时，突然敲响了一记重音（Throw）。乐手们（Fiber 节点）必须立刻停下手中的乐器，让出舞台给新的旋律（高优先级任务）。

而更神奇的是，那个指挥家还非常细心，它记住了刚才乐手们已经演奏过的部分（Completed Effects），在下一次演奏时，直接跳过，只演奏剩下的部分。

这就是 React 能够在复杂的 DOM 操作中，依然保持丝滑流畅的秘密武器。

所以，下次当你点击按钮时，请记住，那不仅仅是一个点击事件。那是一个 Lane，是一把尖刀，刺破了原本平静的渲染循环，逼迫 React 丢掉手中的烂摊子，冲向新的战场。

这就是技术的魅力，这就是代码的艺术。

好了，今天的讲座就到这里。大家现在可以打开电脑，试着在控制台里 throw new Error('hello')，感受一下那种中断的快感（并不推荐在生产环境这样做，除非你想让老板请你喝茶）。

下课！