React 内部调度器与操作系统的线程优先级调度优先级映射

（把投影仪的亮度调高，清清嗓子，把麦克风架调到舒服的高度）

各位好，欢迎来到“React 内部调度器与操作系统线程优先级调度优先级映射”研讨会。坐得离屏幕太近的同学请往回坐一点，这里没有超清无码资源，只有枯燥但刺激的源码剖析。

今天我们不谈 useEffect 的依赖数组，也不谈 Hooks 是如何打破组件封装的；我们谈点更猛的。我们谈谈当你在屏幕上狂点按钮的时候，到底发生了什么？你以为是“啪”一下就跳出来了？错。那是魔法。或者说，那是无数个极其精明的调度员在神经末梢上跳踢踏舞。

在这场舞会中，React 是舞台经理，而你的浏览器内核——那个复杂的、多线程的、有时候甚至有点暴躁的操作系统——是负责分配电力的电网。

今天，我们要把 React 的内部调度器剥光，看看它到底是怎么跟浏览器的线程优先级对暗号的。这不仅仅是代码，这是政治，是阶级斗争，是关于谁先吃饭的哲学。

一、 单线程的监狱与逃逸计划

首先，我们要承认一个残酷的事实：JavaScript 是单线程的。

这就像是你一个人在一家快餐店打工。你一个人要负责点单、炸薯条、做汉堡、擦桌子、送外卖。你的大脑（主线程）只有一个。如果旁边有 100 个顾客同时大喊大叫，你不能同时处理 100 个人。你只能用一种极其高明的策略：排队。

这就是浏览器的模型。所有的渲染任务、脚本执行、用户交互都在这一个线程里。React 做的就是管理这个排队系统。

React 16 之前，它是个只会埋头苦干的傻大个，只要任务一来，它就死干，直到干完。结果就是用户疯狂点击页面，React 还在渲染上一个动画，导致页面卡死，用户就像在泥潭里跑步一样难受。

React 16 之后，我们有了 Scheduler。Scheduler 就像是那个进了消防队的高级调度员。它把巨大的任务切成了无数个小块——这就是 Fiber。Fiber 不仅仅是一个数据结构，它是 React 的呼吸节奏。

而 Scheduler 最核心的功能，就是根据任务的紧急程度，把任务扔进不同的队列里。这时候，问题来了：这些 React 内部的优先级，到底对应着操作系统层面的什么？

二、 React 的优先级等级：从“上帝”到“空气”

在 React 的源码里（scheduler/src/SchedulerPriorities.js），定义了五个等级。我们可以把这想象成公司的职级：

1. NoPriority (0): 没人理你。你是地上的灰尘。
2. ImmediatePriority (99): 老板来了。你的新项目上线了，或者用户输入了连点。
3. UserBlockingPriority (98): 部门经理。他在吼叫，但还没到要开除你的地步。比如一个非关键但很频繁的动画。
4. NormalPriority (97): 普通员工。正常的工作流程，比如数据加载、普通的渲染。
5. LowPriority (96): 实习生。你有空再干。
6. IdlePriority (95): 彻底闲着。比如后台分析数据，或者更新组件的次要属性。

现在，关键的时刻到了。我们的 React Scheduler 怎么把这些数字变成浏览器能听懂的指令？浏览器哪有数字 99？浏览器只有“主线程优先级”和“空闲时间”。

为了把 React 的灵魂注入浏览器的肉体，React 团队（Dan Abramov 神仙团队）做了大量的底层适配。这不仅仅是简单的映射，这是一场跨语言的二进制翻译。

三、 核心映射：Scheduler vs 浏览器 API

既然 JS 在浏览器里跑，它就得用浏览器的 API。而浏览器的 API 本身就有优先级的概念，主要体现在宏任务和微任务的执行顺序，以及 setTimeout 的延迟时间上。

1. ImmediatePriority -> MessageChannel (微任务)

让我们看看 ImmediatePriority。这是最高优先级。用户点了一下按钮，React 必须立即处理这个点击事件，更新 UI，让按钮变红，给用户反馈。如果是老版本的 React，它可能会用 setTimeout(fn, 0)。

但 setTimeout(fn, 0) 实际上不是真的 0 毫秒。浏览器规定，宏任务（MacroTask）的最低延迟通常是 4ms（在 Chrome 中）。这意味着，如果用 setTimeout 处理最高优先级任务，你依然会感觉不到“立即”，你会感觉到了 4ms 的延迟。这对于那种手速极快的游戏玩家来说，简直就是慢动作回放。

所以，React 的 Scheduler 在浏览器中，绝不会用 setTimeout 来处理 ImmediatePriority。

它会使用 MessageChannel 或者 MutationObserver。

// 模拟 React 的 Immediate 逻辑（简化版）
const channel = new MessageChannel();
const port = channel.port2;

channel.port1.onmessage = function() {
    console.log("ImmediatePriority: 我插队了！");
    // 执行最高优先级的渲染任务
    renderHighPriorityWork();
};

// 立即触发
port.postMessage(null);

postMessage 属于 微任务。在浏览器的 Event Loop 中，微任务总是在宏任务之后立即执行。这意味着，postMessage 的响应速度比 setTimeout 快得多，接近于 0。

映射结论：
React 的 ImmediatePriority (99) 映射到了 浏览器的微任务队列。
这是最快的通道，比操作系统的线程优先级还要快（因为线程调度本身也有开销），因为它就在当前调用栈返回后直接执行。

2. UserBlockingPriority -> setTimeout(fn, 0)

这是 UserBlockingPriority (98)。这通常用于那些用户正在交互的动画，比如拖拽元素，或者非关键的高频更新。

虽然它比普通任务高，但比 Immediate 低。这意味着它不需要打断用户当前的输入，但它也不应该让用户感觉到明显的卡顿。

React 会使用 setTimeout(fn, 0) 来处理这类任务。

为什么？因为浏览器倾向于让主线程一直运行。如果你所有的“高优先级”任务都用微任务，那么微任务队列就会堆积如山，导致页面一直无法返回到空闲状态，进而导致键盘输入延迟，焦点丢失。

所以，React 给 UserBlockingPriority 留了 4ms 的缓冲期。这 4ms 的时间，足够浏览器去响应用户的下一次键盘敲击了。

映射结论：
React 的 UserBlockingPriority (98) 映射到了 宏任务队列 (setTimeout 0)。
它被“降级”了，但依然比普通任务快。这是一种妥协的艺术：既保证响应速度，又不堵塞整个系统。

3. NormalPriority -> 正常执行

这是 NormalPriority (97)。这是大多数 React 渲染发生的层级。组件更新、副作用执行，都在这里。

它的执行时机完全取决于浏览器的胃口。当主线程忙完其他事情（比如绘制上一帧），浏览器觉得：“哦，那个 React 97 号先生有点事情要处理，那就让他处理吧。”

映射结论：
React 的 NormalPriority (97) 映射到了 宏任务队列 (正常任务)。
这就是所谓的“随缘更新”。如果有其他高优先级任务在排队，你就等着；如果主线程空闲，你就上来。

4. IdlePriority -> requestIdleCallback

这是最有趣的，也是最符合“操作系统线程优先级”概念的。

React 的 IdlePriority (95) 是给那些不急的任务用的。比如：更新一个列表里每个列表项的“作者名字”，而作者名字是用户根本看不见的（aria-label），或者是在后台聚合数据。

这些任务可以在用户盯着屏幕发呆的时候做。

浏览器提供了 requestIdleCallback API。这个 API 的作用就是告诉浏览器：“嘿，哥们儿，如果你现在有空闲的时间片，就回调我这个函数吧。”

映射结论：
React 的 IdlePriority (95) 映射到了 浏览器的空闲回调。
这基本上就是操作系统线程优先级调度中的“低优先级后台进程”。React 使用这个 API 来榨干浏览器的每一滴剩余性能，而不打扰用户。

四、 深入源码：Priority vs ExpirationTime

光说映射太枯燥了。让我们看点硬核的。在 React 的 Scheduler 包中，除了 PriorityLevel，还有一个核心概念：ExpirationTime。

ExpirationTime 翻译过来就是“过期时间”。这听起来很奇怪，为什么任务会过期？

因为 JS 是单线程的。如果一个任务优先级很低，浏览器一直不给它时间片，它跑着跑着，用户的情况变了，它的优先级可能就从 Low 变成了 Normal，甚至 UserBlocking。

所以，ExpirationTime 是一个动态的截止日期。如果在截止日期之前，任务还没有跑完，React 就必须重新评估它的优先级。

// 简化自 React 源码逻辑
function computeExpirationFromPriority(priorityLevel) {
  switch (priorityLevel) {
    case ImmediatePriority:
      return 1;
    case UserBlockingPriority:
      // 给 50ms 的缓冲期
      return 50; 
    case NormalPriority:
      return 250;
    case LowPriority:
      return 5000;
    case IdlePriority:
      return MAX_TIME;
    default:
      throw new Error('Expected valid priority level');
  }
}

这段代码展示了 React 如何将内部优先级转换为毫秒级的时间窗口。

比如，UserBlockingPriority 有 50ms 的时间。在这 50ms 内，如果有更高优先级的任务（比如用户又点击了一下），React 会立刻中断当前的低优先级任务，去处理高优先级任务。

这就像是一个贪吃蛇游戏：

• ImmediatePriority 是那条最快的蛇，它想怎么吃就怎么吃。
• IdlePriority 是那条最慢的蛇，它吃得很慢，如果它吃了一半，突然有人敲了一下桌子（高优先级事件），那条快蛇就会把慢蛇挤开，快蛇吃完了再回来继续吃慢蛇。

五、 操作系统的视角：为什么不是真正的线程？

你可能会问：“既然有线程优先级，为什么不用线程？”

好问题。这才是真正的高手视角。

如果你的代码运行在 Node.js 里，你可以使用 Worker Threads。Node.js 里有真正的多线程，你可以创建一个线程，给它一个很高的优先级，让它去跑那些耗时计算。

但是，React 主要运行在浏览器中。浏览器（Chrome, Firefox, Safari）并没有暴露给开发者一个“设置线程优先级”的 API。你甚至不能直接创建一个高优先级的线程来跑你的逻辑。

这就是 React Scheduler 的伟大之处。它是在模拟线程调度的行为。

它通过以下手段来欺骗操作系统（或者说欺骗 JS 引擎）：

1. 时间切片： 伪造出多线程并发的假象。每个 Fiber 节点就是一个小任务，任务跑 5ms 就停一下，让出控制权。
2. 队列插队： 高优先级任务总是先执行。
3. 中断机制： 正在跑的低优先级任务，一旦检测到高优先级任务，立即停止，把控制权交出去。

// 模拟 Scheduler 的 workLoop 逻辑
function workLoop() {
  // 1. 查找当前最高优先级的任务
  const nextTask = getHighestPriorityTask();

  if (nextTask === null) {
    return; // 没任务了
  }

  // 2. 执行任务
  nextTask.run();

  // 3. 切片：不要一口气干完，跑 5ms 停一下
  if (shouldYield()) {
    // 如果用户刚刚按了一下键盘，或者系统时间到了，暂停
    return; 
  }

  // 4. 递归调用，继续
  workLoop();
}

function shouldYield() {
  const currentTime = getCurrentTime();
  if (currentTime - startTime > 5) { // 5ms 时间片
    // 真正的浏览器调度在这里介入：此时浏览器会处理 UI 渲染
    return true;
  }
  return false;
}

看懂了吗？这就是 React 在单线程上玩出的花样。它把一个巨大的任务拆解成无数个微小的原子，然后像玩俄罗斯方块一样，把它们排列组合。

六、 实战：从组件到线程

让我们看一个具体的代码示例，看看在开发中，我们是如何不知不觉地影响了这个映射的。

假设我们有一个搜索组件。用户输入文字，我们需要过滤列表。

function SearchComponent() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  // 普通的搜索逻辑，没有过渡
  useEffect(() => {
    const timer = setTimeout(() => {
      const newResults = doHeavySearch(query);
      setResults(newResults);
    }, 300); // 阻塞 300ms

    return () => clearTimeout(timer);
  }, [query]);

  return (
    <ul>
      {results.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  );
}

在旧代码里，用户每打一个字，setTimeout 就会被清空并重置。这会导致页面闪烁，或者卡顿。为什么？因为这里的逻辑默认被分配了 NormalPriority。

如果用户输入速度很快，300ms 的延迟会让用户感觉像是在跟浏览器打架。

如果我们想优化它，我们想利用 React 的调度能力，我们该怎么办？

React 18 引入了 useTransition，这是专门用来处理这种低优先级 UI 更新的。

import { useTransition, useState } from 'react';

function OptimizedSearch() {
  const [isPending, startTransition] = useTransition();
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  const handleChange = (e) => {
    const value = e.target.value;
    setQuery(value);

    // 1. 我们把结果更新标记为 'transition'
    // React 会把这个任务的优先级降低到 Idle 或 Low
    startTransition(() => {
      const newResults = doHeavySearch(value);
      setResults(newResults);
    });
  };

  return (
    <div>
      <input onChange={handleChange} />
      {/* 如果用户快速输入，isPending 会显示“加载中”，但不会阻塞输入框的焦点 */}
      {isPending ? <span>正在思考...</span> : (
        <ul>
          {results.map(item => <li key={item.id}>{item.name}</li>)}
        </ul>
      )}
    </div>
  );
}

这是什么黑魔法？

在这个例子中，React 调度器看到 startTransition 里的更新，不会把它扔进 NormalPriority 队列。它会把它扔进 IdlePriority (或者至少是 LowPriority) 队列。

这意味着什么？

1. 当用户输入时，输入框的焦点更新（ImmediatePriority）会插队，保证输入流畅。
2. 搜索结果列表的更新会被挤到一边，等到浏览器闲下来再慢慢更新。
3. 用户会看到搜索框变蓝（pending 状态），但他依然能流畅地输入下一个字。

这完美地演示了 React 如何通过内部优先级调度，在单线程浏览器环境中，模拟出了多线程高优先级的响应体验。

七、 深入底层的陷阱：Priority vs Time

还有一个非常重要的细节，很多“专家”都搞混了。那就是 Priority 和 Expiration 的关系。

Priority 决定了谁先来。
Expiration 决定了谁先跑完（或者谁必须重新跑）。

想象一下，你是一个厨师（React），你面前有两份订单：

1. 外卖单（ImmediatePriority）： 1 分钟后就要送，不送要赔钱。
2. 家常菜（IdlePriority）： 随便什么时候吃都行。

场景一：
厨师开始做外卖单。他刚切完两片肉，突然传菜员大喊：“有个 VIP 客户要吃家常菜（IdlePriority）！”
结果： 厨师把家常菜扔到一边，继续切肉做外卖单。因为外卖单优先级高。

场景二：
厨师开始做家常菜。他刚煮了 2 分钟，传菜员喊：“外卖单超时了！”
结果： 厨师不得不把家常菜扔到一边，赶紧去救外卖单。这就是 Expiration 的作用。

如果 React 只是依赖 Priority，那么 IdlePriority 的任务可能会一直跑，直到用户把电脑跑死，而 ImmediatePriority 的任务永远进不来。

所以，React 的调度器逻辑是：

1. Check Expiration: 如果当前正在跑的任务已经过期（或者用户在等待关键输入），强行中止低优先级任务，插入高优先级任务。
2. Check Priority: 如果高优先级任务来了，打断当前任务。

代码大概是这个味儿：

// 伪代码：Scheduler 的调度核心
function schedulerLoop() {
  // 1. 获取当前最高优先级任务
  const currentTask = peekHighestPriorityTask();

  // 2. 检查时间片是否用完
  if (currentTime - currentTask.startTime > currentTask.expirationTime) {
    // 任务过期了！哪怕它是低优先级的，也得停下，让路给更高优先级的
    // 这就是为什么有时候你会看到 React 在“重新渲染”，因为上一个任务没跑完，优先级变了
    return;
  }

  // 3. 执行任务
  workStealing(currentTask);

  // 4. 检查是否有更高优先级的新任务进来了
  if (hasNewHigherPriorityTask()) {
    // 撤销当前任务，重新开始
    return;
  }
}

八、 为什么这很重要？

讲了这么多，你可能会说：“老子写个组件，管它什么线程，能跑就行。”

其实不然。理解这个映射，是解决性能问题的根本钥匙。

当你遇到“输入卡顿”时，不要盲目地用 useMemo 或 useCallback 去包裹一切。因为 useMemo 只是缓存了计算结果，并没有改变任务在调度器里的优先级。

如果你在 useEffect 里做了一堆重计算，哪怕你用了 useMemo，只要你的逻辑复杂，React 就会认为这是一个高开销的 NormalPriority 任务。当用户快速输入时，这个任务会堆积在宏任务队列里，导致输入延迟。

正确的姿势是：

1. 识别优先级： 看看你的更新是不是用户正在交互的关键部分？如果是，保持高优先级（Normal 或 UserBlocking）。
2. 隔离耗时： 如果更新不是关键的（比如列表过滤），把它扔进 startTransition，把它变成 IdlePriority。
3. 避免阻塞： 不要在 useEffect 里做任何可能导致长时间阻塞主线程的事情，即使你用了 setTimeout 0。因为 setTimeout 0 依然只是 NormalPriority。

九、 总结：一场宏大的合谋

让我们回到最初的主题。

React 内部调度器，并不是简单地照搬操作系统的线程优先级，因为它们根本不在一个层面上。React 是在模拟一个多线程的、有优先级的操作系统环境。

它利用了浏览器提供的 微任务 和 宏任务 机制，构建了一套自己的优先级体系。

• ImmediatePriority 是潜入微任务队列的刺客，快如闪电。
• UserBlockingPriority 是坐在宏任务队列前排的 VIP，稍微等一下但必须等。
• NormalPriority 是散落在队列各处的路人甲，随缘。
• IdlePriority 是唯一一个真正尊重浏览器“空闲时间”的特权阶级，它使用 requestIdleCallback 在缝隙里生存。

React 的 Fiber 架构配合 Scheduler 优先级系统，就像是一支训练有素的特种部队。在单线程的战场上，他们懂得何时冲锋（Immediate），何时佯攻（UserBlocking），何时撤退（Idle），以最小的代价换取最大的用户体验。

这就是 React 的魔法。它不是在写代码，它是在与浏览器底层协议进行一场精密的外科手术式的谈判。

好了，今天的讲座就到这里。现在的作业是：去读读 scheduler 包的源码，特别是 runWithPriority 和 shouldYield 部分。别问我为什么，问就是这是通往 React 深度理解的第一步。下课！