React 面试细节：请详细阐述 React 调度器如何利用宏任务与微任务的空隙实现对主线程的“温柔占用”

各位好，我是你们的老朋友，一个在 React 源码里摸爬滚打多年的资深“搬砖工”。

今天我们不聊那些花里胡哨的 Hooks，也不谈什么 SSR 的玄学。今天我们要聊的是 React 的“心脏”深处，那个最隐秘、最优雅，同时也是最累人的部分——调度器。

大家平时写 React，点一下按钮，页面就变了。这感觉就像魔术师挥挥袖子，变出一朵花。但你有没有想过，为什么这朵花是慢慢变出来的，而不是像发牌一样“啪”一下全甩在脸上？为什么页面不会卡死，为什么浏览器不会报“脚本运行时间过长”的警告？

这就涉及到了今天的话题：React 调度器如何利用宏任务与微任务的空隙，实现对主线程的“温柔占用”。

这听起来很高大上，对吧？其实说白了，就是 React 这个“管家”，在浏览器这个“暴躁老板”发火之前，偷偷溜进空档期，把活儿干完。

咱们废话少说，直接进入正题。

---

第一部分：浏览器的“混乱派对”——宏任务与微任务

要理解 React 的调度，首先你得明白浏览器的主线程是个什么样子的。它不是那种安静的图书馆，它更像是一个24小时不停歇的嘈杂派对。

在这个派对上，有两个主要的“角色”在轮流掌控局面：宏任务和微任务。

1. 宏任务：那些“大老板”

宏任务就像是派对上的“大老板”。他们地位高，动静大，而且出场有规矩。
谁算宏任务呢？主要是：

• setTimeout / setInterval：老板说，“我给你五分钟，五分钟后你来开会”。
• DOM 事件：比如你点击了屏幕，这是个大事件，得停下来处理。
• I/O 操作：比如你去服务器要个数据，这得等半天，是个大活儿。
• UI 渲染：浏览器每帧都要画图，这也是个大活儿。

规则是： 宏任务执行完，浏览器会检查一下有没有紧急的“微任务”要处理，然后再去执行下一个宏任务。

2. 微任务：那些“急死人的秘书”

微任务就像是老板的“秘书”。他们地位低，但跑得快，执行力极强。
谁算微任务呢？

• Promise.then：这是最典型的。老板刚布置完任务（宏任务结束），秘书马上就拿着笔记来了，“老板，这个任务我处理完了，您看行不行？”
• queueMicrotask：更底层的微任务队列。

规则是： 每当宏任务执行完毕，微任务队列会立即清空。一旦清空完，浏览器才会去考虑下一帧的渲染或者下一个宏任务。

3. 那个“空隙”在哪？

大家看，流程是这样的：

1. 宏任务 A 开始干活（比如处理点击事件）。
2. 宏任务 A 干完了。
3. 微任务队列 被清空（比如处理 Promise.then）。
4. 浏览器 准备下一帧渲染（画图）。
5. 关键来了： 在渲染之前，浏览器通常会给主线程一个喘息的机会。这时候，如果主线程没事干，它就会进入空闲状态。

React 调度器的绝活，就是盯着这个空闲状态。它不抢宏任务的风头（不让点击卡顿），也不跟微任务抢速度（不让 Promise 失效），它就在宏任务和微任务之间的那个微小的空隙里，溜进来干点活。

---

第二部分：React 的“暴脾气”与“温柔药”

在 React 15 之前，事情是这样的：
你点击一下按钮 -> React 开始计算差异 -> React 开始渲染 -> 主线程被锁死 500ms -> 用户看到页面白屏 -> 用户疯狂点击 -> 浏览器崩溃。

为什么？因为 React 15 是同步的。它就像一个不会停下来的推土机，不管主线程多累，它都要把树全建好。

React 16 之后，React 团队决定搞事情了。他们写了一个独立的包，叫 Scheduler（调度器）。这个调度器是个什么玩意儿呢？它不是 React 的核心，但它控制着 React 的生杀大权。

它的核心思想就两个字：切片。

React 不想把整个树一次性渲染完。它想把它切成一万片，一片只干 5 毫秒，干不完就停下来，让主线程去处理用户的下一次点击，等用户点完了，React 再溜回来继续干。

怎么实现这个“切片”呢？靠的就是那个神奇的 API——requestIdleCallback。

---

第三部分：调度器的“温柔战术”详解

React 的调度器（特别是 Scheduler 包）利用 requestIdleCallback 来捕获主线程的空闲时间。

1. 优先级的艺术

React 的调度器不是瞎忙活的。它知道有些事很重要（比如用户正在输入），有些事可以晚点做（比如数据加载完后的页面更新）。
所以，调度器内部维护了一个任务优先级队列。

• 高优先级：用户交互（点击、输入）。
• 中优先级：动画帧更新。
• 低优先级：后台数据同步。

2. 宏任务与微任务中的“空隙”利用

这是重点，我们得画个图来理解。

假设用户点击了一个按钮（宏任务）：

1. 阶段一：宏任务执行

   • 浏览器执行点击事件的回调函数。
   • React 收集了状态变更，计算出新的 Fiber 树（或者标记了需要更新的节点）。
   • React 调度器登场：它把“执行渲染”这个任务扔进了宏任务队列里。
   • 宏任务结束。浏览器准备去执行微任务。

2. 阶段二：微任务执行

   • 浏览器清空微任务队列（比如 Promise.then 回调）。
   • 此时，主线程已经把刚才那个宏任务（点击处理）干完了，微任务也干完了。
   • 主线程进入空闲状态。浏览器会触发 requestIdleCallback。

3. 阶段三：React 的“温柔占用”

   • React 的调度器监听到了 requestIdleCallback。
   • 它会检查：我现在手里有任务吗？有！
   • 它会计算：我现在能干多久？浏览器传给我一个 deadline 对象，告诉我还有多少时间（比如 5ms）。
   • 开始干活：React 拿出刚才计算好的 Fiber 树，开始渲染前几帧。
   • 时间到：5ms 过了。deadline 变成了 0。
   • React 暂停：React 立刻停止工作，把控制权还给浏览器。它甚至不会去检查微任务队列，因为它知道那是老板（浏览器）的事。

4. 阶段四：下一帧

   • 浏览器处理完微任务，准备下一帧渲染。
   • 如果渲染完成还有空隙，requestIdleCallback 再次触发。
   • React 再次溜进来，把刚才没干完的活接着干。

这就叫“温柔占用”。React 就像一个在办公室偷懒的员工，老板（浏览器）一有空档，他就溜进去干两分钟，老板一瞪眼，他立马趴在桌子上装死。

---

第四部分：代码演示——手写一个“React 调度器”

为了让大家更直观地理解，我不藏私了。下面是一个简化版的 React 调度器实现。

注意，这只是一个概念验证，真正的 React 调度器复杂一万倍，但它完美地展示了利用宏微任务空隙的原理。

// 模拟宏任务和微任务环境
class MockEventLoop {
  constructor() {
    this.queue = [];
    this.microtaskQueue = [];
    this.isRunning = false;
  }

  // 模拟一个宏任务（比如用户点击）
  scheduleMacroTask(callback) {
    this.queue.push(callback);
    if (!this.isRunning) {
      this.isRunning = true;
      this.runNextMacroTask();
    }
  }

  // 模拟微任务（比如 Promise.then）
  scheduleMicrotask(callback) {
    this.microtaskQueue.push(callback);
  }

  // 运行宏任务
  async runNextMacroTask() {
    if (this.queue.length === 0) {
      this.isRunning = false;
      return;
    }
    const task = this.queue.shift();
    console.log(`[宏任务] 开始执行: ${task.name}`);
    const start = performance.now();
    task.fn();
    const end = performance.now();
    console.log(`[宏任务] 结束: ${task.name}, 耗时: ${end - start}ms`);

    // 宏任务结束后，执行所有微任务
    await this.runMicrotasks();
  }

  // 运行微任务
  async runMicrotasks() {
    if (this.microtaskQueue.length === 0) return;

    // 模拟微任务执行期间，主线程被微任务占满
    console.log(`[微任务] 开始清理微任务队列...`);
    while (this.microtaskQueue.length > 0) {
      const microtask = this.microtaskQueue.shift();
      microtask();
      // 模拟微任务也耗时
      await new Promise(r => setTimeout(r, 1));
    }
    console.log(`[微任务] 微任务队列已清空。`);
  }

  // 模拟 requestIdleCallback
  // 注意：真实浏览器中，requestIdleCallback 在微任务之后、下一帧渲染之前触发
  simulateIdleCallback(deadline, callback) {
    // 这里我们用 setTimeout 模拟浏览器的主线程空闲时刻
    // 在真实场景中，这由浏览器内核管理
    setTimeout(() => {
      // 模拟浏览器给 React 的时间切片
      let timeLeft = deadline.timeRemaining();

      console.log(`[空闲时间] React 接管主线程，剩余时间: ${timeLeft.toFixed(2)}ms`);

      // React 开始干活
      callback(deadline);
    }, 0);
  }
}

// ---------------------------------------------------------
// 下面是 React 调度器的逻辑（简化版）
// ---------------------------------------------------------

class ReactScheduler {
  constructor(eventLoop) {
    this.eventLoop = eventLoop;
    this.workQueue = []; // 待执行的任务队列
    this.isRendering = false;
  }

  // 用户点击事件触发
  handleClick() {
    console.log("用户点击了按钮，状态更新了！");

    // 1. 计算差异（这里简化为直接把任务加入队列）
    this.workQueue.push({
      id: 1,
      name: "渲染第一帧",
      execute: (deadline) => this.renderFrame(deadline)
    });

    // 2. 关键点：React 不直接执行，而是把这个宏任务扔给事件循环
    this.eventLoop.scheduleMacroTask({
      name: "React 渲染主流程",
      fn: () => this.processWork()
    });
  }

  // 核心渲染逻辑
  renderFrame(deadline) {
    console.log("React 开始渲染...");

    let shouldYield = false;

    // 时间切片循环
    while (this.workQueue.length > 0) {
      // 检查是否还有剩余时间
      if (deadline.timeRemaining() <= 0) {
        shouldYield = true;
        console.log("时间到！React 停下来，把控制权还给浏览器。");
        break;
      }

      // 取出任务执行
      const task = this.workQueue.shift();
      console.log(`  -> 正在执行: ${task.name}`);

      // 模拟渲染耗时
      // 注意：这里不使用 setTimeout，而是直接计算时间
      const startTime = performance.now();
      // 假设渲染逻辑需要 2ms
      while (performance.now() - startTime < 2) {
        // 忙等待，模拟计算
      }

      // 如果还有任务，继续
    }

    if (shouldYield) {
      // 如果没干完，立刻把剩下的任务重新放回队列
      // 然后等待下一帧的空闲时间
      console.log("React 暂停工作，等待下一帧空闲。");
      this.eventLoop.scheduleMacroTask({
        name: "React 继续渲染",
        fn: () => this.processWork()
      });
    } else {
      console.log("React 渲染全部完成！");
    }
  }

  // 主调度入口
  processWork() {
    if (this.workQueue.length === 0) return;

    // 这里的逻辑其实就是 React 内部调用的 requestIdleCallback
    this.eventLoop.simulateIdleCallback(
      { timeRemaining: () => 5 }, // 假设浏览器给 5ms 时间
      (deadline) => this.renderFrame(deadline)
    );
  }
}

// ---------------------------------------------------------
// 运行测试
// ---------------------------------------------------------
const loop = new MockEventLoop();
const scheduler = new ReactScheduler(loop);

// 1. 用户点击
scheduler.handleClick();

// 2. 浏览器处理宏任务
// (控制台会看到宏任务开始，微任务执行，空闲时间到来)

运行结果解析：

1. 宏任务启动：[宏任务] 开始执行: React 渲染主流程。
2. 微任务清理：宏任务结束后，微任务立即执行。
3. 空闲时间降临：微任务清空后，[空闲时间] React 接管主线程。
4. 切片渲染：[空闲时间] 正在执行: 渲染第一帧。
5. 时间耗尽：2ms 过后，[空闲时间] 时间到！React 停下来...。
6. 等待下一帧：React 不会傻等，它把剩下的任务扔回队列，等待下一次宏任务触发。

看懂了吗？这就是 React 调度器的精髓。它没有在宏任务里死磕，也没有在微任务里乱窜，它就是利用那个微任务执行完、下一帧渲染前的那个瞬间，溜进来干活的。

---

第五部分：深入 Fiber 架构——为什么能“切”？

光有时间切片还不够，你得有地方“切”啊。如果 React 的代码是一坨长面条，你切断了面条也变不成饺子。所以，React 16 引入了 Fiber 架构。

Fiber 是 React 的虚拟 DOM 节点的升级版。它不仅仅是数据，它是一个执行单元。

每个 Fiber 节点都有一个属性：

• child: 第一个子节点。
• sibling: 下一个兄弟节点。
• return: 父节点。

这种结构非常关键。它让 React 可以像遍历链表一样遍历树。

1. 双缓冲技术

React 在渲染时，维护了两棵树：

• Current Tree: 当前显示在屏幕上的树。
• WorkInProgress Tree: 正在构建的新树。

React 在 WorkInProgress Tree 上进行所有的计算、差异比对。一旦计算完成，React 会把 WorkInProgress 标记为 Current，把原来的 Current 变成 WorkInProgress。

2. 中断与恢复

因为 Fiber 是链表结构，React 在遍历时，随时可以打断。
比如，React 正在渲染第 100 个节点，突然时间到了（deadline 为 0）。
React 只需要：

1. 记录当前遍历到的指针位置。
2. 保存当前的计算状态。
3. 把控制权交还给浏览器。

等到下一次 requestIdleCallback 触发，React 从记录的指针位置继续往下遍历，就像接力赛一样，无缝衔接。

这就是为什么 React 能做到“温柔占用”。因为它根本不知道什么是“全部渲染完”，它只知道“当前这个节点我能不能在 deadline 时间内搞定”。

---

第六部分：优先级的博弈

调度器不仅仅是“有空就干”，它还必须得知道谁该先干。

如果用户正在疯狂点击按钮（高优先级），同时后台发来一个数据更新（低优先级），React 怎么办？

React 的调度器会维护一个任务优先级队列。

1. 用户点击 -> 任务 A（高优先级）加入队列。
2. 后台数据 -> 任务 B（低优先级）加入队列。
3. React 拿到一个空闲时间块。
4. React 检查队列：发现任务 A 在那里等着呢！
5. React 抛弃 任务 B，先执行任务 A。
6. 任务 A 执行完，或者时间到了，React 再回头看任务 B。

这就是所谓的抢占式调度。高优先级的任务就像一个暴君，随时可以把低优先级的任务踢出队列。

而且，React 还有一个机制叫调度回滚。如果在执行任务 A 的时候，又来了一个更紧急的任务 C，React 会立即中止任务 A，去执行任务 C。等任务 C 完了，React 还会回到任务 A 的断点继续执行（如果任务 A 还是高优先级的话）。

---

第七部分：总结——React 的优雅哲学

好了，讲了这么多，我们回过头来看看 React 调度器是如何实现“温柔占用”的。

它不是在跟浏览器抢地盘，它是在利用浏览器的节奏。

1. 宏观层面：它利用宏任务的间隙（比如事件处理完），将渲染任务排期。
2. 微观层面：它利用微任务清空后的空闲时间（requestIdleCallback），在下一帧渲染前，偷偷摸摸地把 DOM 更新一点点。
3. 技术实现：它利用 Fiber 架构，将庞大的渲染任务拆解成无数个小任务，每个小任务都可以被中断和恢复。
4. 核心策略：时间切片。通过限制每次执行的时间，确保主线程始终有喘息的机会，保证 UI 的流畅性。

这种设计哲学非常符合 React 团队的风格：不追求一蹴而就，追求细水长流；不追求绝对的完美（一次性渲染），追求在有限资源下的极致体验。

当你下次在代码里写下 setState，看着页面平滑地更新时，请记住，在屏幕的背后，有一个名叫 Scheduler 的调度员，正拿着秒表，在宏任务和微任务的夹缝中，优雅地跳着踢踏舞，为你守护着主线程的安宁。

这，就是 React 的调度器。谢谢大家。