深度拆解 `performUnitOfWork`：React 是如何在执行过程中“停下来”把控制权还给浏览器的？

在现代Web应用中，用户体验的核心在于界面的响应速度和流畅性。然而，JavaScript作为单线程语言，在处理复杂或计算密集型任务时，极易陷入“长任务”的困境，导致页面卡顿、动画不流畅，甚至完全无响应，给用户带来糟糕的体验。传统的UI渲染模式，往往是同步且阻塞的，一旦开始渲染，就必须一口气完成所有工作，才能将控制权交还给浏览器。这对于日益复杂的交互和数据处理场景来说，显然是不可持续的。

React，作为主流的前端框架，在早期的版本中也面临着同样的挑战。其旧的协调器（Stack Reconciler）采用递归方式遍历组件树，一旦更新发生，整个渲染过程就会阻塞主线程，直到所有组件都完成协调和渲染。为了彻底解决这一问题，React从零开始重构了其核心架构，引入了Fiber Reconciler和并发模式（Concurrent Mode），其核心思想便是将渲染工作分解为可中断、可恢复的“单元”，并以协作式多任务的方式与浏览器进行调度。

本文将深入探讨React的这一革命性机制，特别是围绕 performUnitOfWork 这个核心函数，来剖析React是如何在执行过程中“停下来”，将控制权交还给浏览器，从而实现流畅的用户体验。

一、JavaScript单线程的困境与合作式多任务的崛起

JavaScript在浏览器中运行于主线程，这意味着所有UI渲染、事件处理、网络请求回调以及JavaScript代码执行都共享同一个线程。当一个JavaScript任务执行时间过长（通常超过50毫秒），浏览器就无法及时响应用户输入、更新UI，从而导致“卡顿”或“冻结”现象。这就是所谓的“长任务”问题。

为了解决这个问题，Web开发领域引入了多种策略：

1. Web Workers: 将计算密集型任务 offload 到独立的线程。但这无法直接操作DOM，且通信成本较高。
2. 异步编程: 使用setTimeout, Promise, async/await 等，将任务分解成小块，在不同的事件循环轮次中执行。但这仍然需要手动管理任务分解，并且缺乏对任务优先级的细粒度控制。
3. 合作式多任务（Cooperative Multitasking）: 这是一种由应用程序自身主动将控制权交还给操作系统（或浏览器）的调度方式。与抢占式多任务不同，它不依赖外部强制中断，而是任务自身决定何时暂停。React的并发模式正是这种思想的极致实践。

React的Fiber架构，正是为实现合作式多任务而生。它将传统的递归遍历组件树的方式，改造成了迭代遍历，并且在每次迭代中，都检查是否需要将控制权交还给浏览器。

二、Fiber架构：可中断的渲染单元

在深入 performUnitOfWork 之前，我们必须理解Fiber架构。Fiber是React 16及以后版本引入的核心协调器（Reconciler）的底层实现。它取代了原有的Stack Reconciler，带来了革命性的变化。

2.1 Fiber：工作单元的抽象

在Fiber架构中，一个Fiber节点代表一个组件实例、一个DOM元素、一个文本节点或任何其他React可以渲染的单元。每个Fiber节点都包含了以下关键信息：

• type: 元素的类型（例如，'div'、MyComponent）。
• key: 用于列表渲染的key属性。
• props: 元素的属性。
• stateNode: 对应到真实DOM节点或组件实例的引用。
• return: 指向其父级Fiber节点。
• child: 指向其第一个子级Fiber节点。
• sibling: 指向其下一个兄弟Fiber节点。
• alternate: 指向“双缓冲”中的另一个Fiber节点。在更新过程中，React会构建一个新的Fiber树（workInProgress树），这个alternate指针就连接着当前（current）树中的对应节点。
• effectTag: 标记该Fiber节点需要执行的副作用（如插入、更新、删除DOM等）。
• expirationTime / lanes: 用于优先级调度，表示该Fiber的更新何时应该完成。

Fiber树的结构类似于一个单向链表，但通过child、sibling、return指针，可以高效地进行深度优先遍历。

2.2 工作流程概览：渲染的两阶段

React的渲染过程被划分为两个主要阶段：

1. 协调/渲染阶段 (Render Phase)：

   • 这个阶段是可中断的。
   • React会遍历Fiber树，执行组件的render方法，计算新的组件状态和属性，并生成新的子Fiber节点。
   • 在这个阶段，React会找出所有需要对DOM进行的修改（即副作用），并将它们标记在Fiber节点上（通过effectTag）。
   • 这个阶段不会实际修改DOM。
   • performUnitOfWork主要发生在这个阶段。

2. 提交阶段 (Commit Phase)：

   • 这个阶段是同步且不可中断的。
   • React遍历在渲染阶段标记了副作用的Fiber节点，并一次性地将所有DOM操作应用到真实DOM上。
   • 执行生命周期方法（如componentDidMount、componentDidUpdate、useLayoutEffect）和处理DOM引用。
   • 这个阶段必须快速完成，因为它会阻塞主线程。

正是渲染阶段的可中断性，使得React能够实现“暂停”和“恢复”的能力。

三、performUnitOfWork：原子化的工作单元处理

performUnitOfWork 是React渲染阶段的核心函数。它负责处理单个Fiber节点，是React协调算法中的一个“原子”操作。每次调用 performUnitOfWork，React都会处理一个Fiber节点，并返回下一个需要处理的Fiber节点。

3.1 performUnitOfWork 的职责

当 performUnitOfWork 被调用时，它会执行以下主要任务：

1. 处理当前Fiber节点:

   • 对于函数组件，它会调用组件函数并获取其返回的JSX。
   • 对于类组件，它会实例化组件并调用其render方法。
   • 对于宿主组件（如div, span），它会处理其属性。
   • 在这个过程中，它会根据新旧props/state计算出新的子元素结构。

2. 协调子Fiber节点:

   • 将当前Fiber节点（workInProgress）的子元素与现有Fiber树（current）中的子元素进行比较（即diffing算法）。
   • 根据比较结果，创建新的子Fiber节点、更新现有子Fiber节点或标记需要删除的子Fiber节点。
   • 将这些子Fiber节点链接到 workInProgress 树中。

3. 标记副作用:

   • 如果当前Fiber节点或其子节点需要进行DOM操作（如插入、更新、删除），或者需要触发生命周期方法/Hook回调，performUnitOfWork 会在Fiber节点上设置相应的 effectTag。

4. 返回下一个工作单元:

   • 根据深度优先遍历的原则，performUnitOfWork 会返回下一个需要处理的Fiber节点。如果当前Fiber有子节点，则返回第一个子节点；如果没有子节点但有兄弟节点，则返回兄弟节点；否则，它会向上回溯到父节点，并尝试返回父节点的兄弟节点，直到找到下一个工作单元或遍历完成。

3.2 简化代码示例：performUnitOfWork 的内部逻辑

为了更好地理解，我们用一个高度简化的伪代码来模拟 performUnitOfWork 的核心逻辑。请注意，实际的React代码要复杂得多，涉及优先级、各种组件类型、Hooks、上下文等。

// 假设这是React内部的Fiber节点结构
class Fiber {
    constructor(tag, pendingProps, key) {
        this.tag = tag; // e.g., HostComponent (div), FunctionComponent, ClassComponent
        this.pendingProps = pendingProps;
        this.memoizedProps = null; // Props used for the last successful render
        this.memoizedState = null; // State used for the last successful render

        this.elementType = null; // e.g., 'div', MyComponent.type
        this.type = null;        // e.g., 'div', MyComponent

        this.stateNode = null; // DOM node or component instance

        this.return = null; // Parent Fiber
        this.child = null;  // First child Fiber
        this.sibling = null; // Next sibling Fiber

        this.alternate = null; // The Fiber from the current tree
        this.effectTag = NoEffect; // Flags for side effects
        this.updateQueue = null; // Queue for updates (e.g., setState)

        // For scheduling and priority
        this.lanes = NoLanes;
        this.childLanes = NoLanes;

        // ... many more properties
    }
}

// 假设我们有一个全局变量来追踪下一个要处理的工作单元
let nextUnitOfWork = null;
let workInProgressRoot = null; // The root of the work-in-progress tree

/**
 * 协调子节点的核心函数
 * 负责比较当前子节点和旧子节点，生成新的Fiber节点或标记现有节点
 */
function reconcileChildren(current, workInProgress, nextChildren) {
    // 实际的reconciliation算法非常复杂，这里只是一个概念性的简化
    // 它会进行key的比较、类型的比较，找出插入、更新、删除的节点
    // 并将它们构建成 workInProgress.child, workInProgress.sibling 链表

    let newChild = null; // 假设通过diffing创建了新的子Fiber
    // ... 实际的diffing逻辑 ...

    if (newChild) {
        newChild.return = workInProgress;
        workInProgress.child = newChild;
    }
    // 返回第一个子节点
    return newChild;
}

/**
 * 处理单个Fiber节点的核心函数
 * @param {Fiber} currentFiber - 当前要处理的workInProgress Fiber节点
 * @returns {Fiber | null} - 下一个要处理的Fiber节点，或者 null 表示当前子树已完成
 */
function performUnitOfWork(currentFiber) {
    // 1. 根据Fiber的类型（函数组件、类组件、宿主组件等）执行不同的操作
    switch (currentFiber.tag) {
        case FunctionComponent:
            // 假设我们有一个函数来渲染FunctionComponent
            // 这会调用组件函数，并处理Hooks
            updateFunctionComponent(currentFiber);
            break;
        case ClassComponent:
            // 假设我们有一个函数来渲染ClassComponent
            updateClassComponent(currentFiber);
            break;
        case HostComponent: // e.g., <div>, <span>
            // 宿主组件主要处理其props，并准备子元素的协调
            updateHostComponent(currentFiber);
            break;
        // ... 其他Fiber类型，如HostText, MemoComponent, SuspenseComponent, etc.
    }

    // 2. 协调子节点：将组件的渲染结果（JSX）转换为Fiber树
    // currentFiber.pendingProps.children 代表组件render方法返回的子元素
    const nextChildren = currentFiber.pendingProps.children;
    reconcileChildren(currentFiber.alternate, currentFiber, nextChildren);

    // 3. 返回下一个工作单元 (深度优先遍历)
    // 如果有子节点，则处理子节点
    if (currentFiber.child !== null) {
        return currentFiber.child;
    }

    // 如果没有子节点，则尝试处理兄弟节点
    let nextFiber = currentFiber;
    while (nextFiber !== null) {
        // 在完成当前节点及其所有子节点的工作后，将副作用向上冒泡
        // 这个过程在实际中更复杂，涉及 completeUnitOfWork
        // 这里只是为了简化说明，假设副作用标记已完成

        if (nextFiber.sibling !== null) {
            return nextFiber.sibling;
        }
        // 如果没有兄弟节点，则回到父节点，并尝试处理父节点的兄弟节点
        nextFiber = nextFiber.return;
    }

    // 如果所有工作都完成了（回溯到根节点且没有兄弟节点），则返回null
    return null;
}

// 辅助函数 (简化)
function updateFunctionComponent(workInProgress) {
    // 模拟调用函数组件的render方法，并处理Hooks
    // const children = MyComponent(workInProgress.pendingProps);
    // workInProgress.memoizedProps = workInProgress.pendingProps;
    // ...处理Hooks state, effects...
}

function updateClassComponent(workInProgress) {
    // 模拟调用类组件的render方法
    // const instance = workInProgress.stateNode || new workInProgress.type(workInProgress.pendingProps);
    // workInProgress.stateNode = instance;
    // const children = instance.render();
    // workInProgress.memoizedProps = workInProgress.pendingProps;
    // workInProgress.memoizedState = instance.state;
}

function updateHostComponent(workInProgress) {
    // 宿主组件的处理通常比较简单，主要是更新props
    // 这里可能会标记 effectTag 来表示需要更新DOM
    // workInProgress.memoizedProps = workInProgress.pendingProps;
}

从上述伪代码中可以看出，performUnitOfWork 每次只处理一个Fiber节点，并明确地返回下一个要处理的节点。这种迭代式的处理方式，为React实现“暂停”和“恢复”奠定了基础。

四、工作循环：workLoopSync vs. workLoopConcurrent

performUnitOfWork 是一个原子操作，但它需要在一个循环中被反复调用，才能完成整个Fiber树的协调。React提供了两种主要的工作循环模式：同步模式和并发模式。

4.1 workLoopSync：传统的阻塞模式

在React的早期版本，或者在并发模式被禁用、或者处理高优先级（如同步更新，LegacyRoot）的更新时，React会使用 workLoopSync。

// 在实际React代码中，这个循环会处理workInProgressRoot，
// 并最终在nextUnitOfWork变为null时完成
function workLoopSync() {
    // 只要有下一个工作单元，就一直执行
    while (nextUnitOfWork !== null) {
        nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
    }
}

workLoopSync 是一个简单的while循环，它会不间断地调用 performUnitOfWork，直到所有工作都完成。这意味着一旦 workLoopSync 开始执行，它就会完全阻塞主线程，直到 nextUnitOfWork 变为 null。这种模式效率高（没有调度开销），但会导致UI卡顿。

4.2 workLoopConcurrent：可中断的协作模式

并发模式下的工作循环是 workLoopConcurrent。它引入了一个关键的条件判断：!shouldYield()，这正是React能够“停下来”的核心。

function workLoopConcurrent() {
    // 只要有下一个工作单元，并且“现在不需要将控制权交还给浏览器”
    while (nextUnitOfWork !== null && !shouldYield()) {
        nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
    }

    // 如果循环是因为 shouldYield() 返回 true 而中断
    if (nextUnitOfWork !== null) {
        // 说明工作没有完成，需要安排在稍后继续
        // 这里会调用调度器，将剩余工作重新安排到下一个可用的时间片
        schedulePerformWorkUntilDeadline(); // 伪代码，实际是scheduler.scheduleCallback
    } else {
        // 如果 nextUnitOfWork 为 null，说明所有渲染工作都已完成
        // 可以进入提交阶段 (commit phase)
        commitRoot(workInProgressRoot);
    }
}

workLoopConcurrent 的关键区别在于 !shouldYield() 条件。每执行完一个 performUnitOfWork，React都会检查 shouldYield()。如果 shouldYield() 返回 true，则意味着当前时间片已用尽，或者有更高优先级的任务需要执行，workLoopConcurrent 会立即停止执行，将控制权交还给浏览器。

当 workLoopConcurrent 停止后，nextUnitOfWork 仍然指向未完成的Fiber节点。React的调度器会记住这个状态，并在浏览器下次空闲时，或者在下一个调度周期到来时，重新调用 workLoopConcurrent，从中断的地方继续执行。

五、shouldYield() 与 React 调度器：时间切片的核心

shouldYield() 函数是实现合作式多任务的关键。它不是React协调器的一部分，而是由React的独立调度器（Scheduler）库提供的。React Scheduler是一个通用任务调度器，它不依赖于React本身，也可以用于其他场景。

5.1 React Scheduler 的作用

React Scheduler 的主要职责是：

• 任务优先级管理: 允许开发者为不同的任务指定不同的优先级（例如，用户输入事件的优先级高于数据加载）。
• 时间切片 (Time Slicing): 将长时间运行的任务分解成小块，在每个浏览器帧中只执行一小部分，然后将控制权交还给浏览器，确保UI的响应性。
• 并发任务调度: 管理多个并发任务，根据优先级和剩余时间决定哪个任务应该执行。

5.2 shouldYield() 的内部机制

shouldYield() 的判断逻辑主要基于两个因素：

1. 当前任务的过期时间 (expirationTime / deadline): 每个调度任务都有一个计算出的 expirationTime，表示该任务最迟应该在何时完成。
2. 当前帧的剩余时间: 调度器会跟踪当前浏览器帧中还剩下多少时间来执行JavaScript。

// 极度简化的 shouldYield 伪代码
let currentTaskDeadline = 0; // 当前任务的截止时间
let frameInterval = 5; // 假设每个时间片为 5ms (可配置)
let startTime = 0; // 当前时间片的开始时间

function scheduleCallback(priority, callback) {
    const currentTime = performance.now();
    // 根据优先级计算任务的过期时间
    currentTaskDeadline = currentTime + frameInterval; // 简化处理，实际更复杂

    // 使用浏览器API (如 MessageChannel) 安排在下一个宏任务中执行 workLoopConcurrent
    // 实际的调度器会维护一个任务队列
    requestHostCallback(callback);
}

function requestHostCallback(callback) {
    // 在浏览器支持 requestIdleCallback 时使用它作为 fallback
    // 但通常使用 MessageChannel 来获得更精确和可控的调度
    if (typeof MessageChannel !== 'undefined') {
        const channel = new MessageChannel();
        channel.port1.onmessage = () => {
            startTime = performance.now(); // 记录当前时间片的开始时间
            try {
                callback(); // 执行 workLoopConcurrent
            } finally {
                // 如果任务未完成，再次调度
                if (nextUnitOfWork !== null) {
                    requestHostCallback(callback);
                }
            }
        };
        channel.port2.postMessage(null);
    } else {
        // Fallback to setTimeout for older browsers
        setTimeout(callback, 0);
    }
}

function shouldYield() {
    const currentTime = performance.now();
    // 检查是否已经超过了当前时间片的截止时间
    // 或者是否有更高优先级的任务正在等待
    return currentTime >= currentTaskDeadline;
}

关键点解释：

• performance.now(): 这是一个高精度计时器，用于获取自页面加载以来的毫秒数，比 Date.now() 更精确，适合测量时间间隔。
• MessageChannel: 这是浏览器提供的一种异步通信机制，允许在不同的执行上下文之间发送消息。React Scheduler利用它来模拟一个“宏任务”，从而在每个浏览器帧的间隙中精确地调度JavaScript任务。相比 setTimeout(fn, 0)，MessageChannel 的延迟更低，且可以避免被浏览器限制为最小4ms延迟，提供了更细粒度的控制。它比 requestAnimationFrame 更早执行，因为它不与绘制操作绑定。
• currentTaskDeadline: 调度器会根据任务的优先级和预设的时间切片长度（例如，5ms），计算出一个 currentTaskDeadline。workLoopConcurrent 在执行 performUnitOfWork 之后，会立即检查 performance.now() 是否已经超过了这个 currentTaskDeadline。
• 高优先级任务的抢占: shouldYield() 还会检查是否有更高优先级的任务已经在调度器中等待。如果有，即使当前时间片未用尽，它也可能返回 true，以便高优先级任务能够尽快执行。

当 shouldYield() 返回 true 时，workLoopConcurrent 就会中断，把控制权还给浏览器。浏览器可以趁此机会执行布局、绘制、处理用户输入等任务，保持UI的响应性。然后，在下一个合适的时机（通常是下一个 MessageChannel 宏任务被触发时），调度器会重新唤醒 workLoopConcurrent，让它从上次中断的地方继续执行。

5.3 调度器优先级表格

React Scheduler定义了不同的任务优先级，以指导 shouldYield() 的决策：

优先级名称	数值 (越小优先级越高)	描述	典型应用场景	截止时间 (近似)
Immediate	-1	立即执行，同步阻塞。	用户输入事件的同步回调，确保一致性。	0 (立即)
UserBlocking	250	用户正在等待响应，需要快速完成。	用户点击、拖拽、输入框更新。	currentTime + 250ms
Normal	5000	常规任务，可以稍微延迟。	大部分非紧急的渲染更新、数据获取。	currentTime + 5000ms
Low	10000	可以延迟执行，不影响用户体验。	非关键数据的预加载、不重要的动画。	currentTime + 10000ms
Idle	Infinity	只有在浏览器完全空闲时才执行，可以无限延迟。	离屏元素的渲染、错误上报、分析数据发送。	Infinity

shouldYield() 在判断时，会结合当前任务的优先级和已分配的时间片。如果当前执行的是一个 Low 优先级的任务，并且时间片已用尽，它会更容易 yield。而对于 UserBlocking 任务，调度器会尝试分配更多的时间，或者更少地 yield，以尽快完成。

六、并发更新的完整生命周期

现在，我们将 performUnitOfWork、workLoopConcurrent 和 shouldYield() 结合起来，描绘一个典型的并发更新生命周期：

1. 触发更新: 用户与UI交互（例如，点击按钮），或者数据请求完成后调用 setState。React接收到更新请求，并为其分配一个优先级和过期时间。
2. 调度工作: React将这个更新任务通过 scheduleCallback 函数提交给 Scheduler。Scheduler将其放入内部的任务队列，并安排一个宏任务（通常通过 MessageChannel）在浏览器下一个可能的空闲时段执行。
3. 开始渲染阶段:
   • 当Scheduler的宏任务被触发时，它会调用 workLoopConcurrent。
   • workLoopConcurrent 开始执行，并初始化 nextUnitOfWork 为Fiber树的根节点。
   • 循环开始：performUnitOfWork(nextUnitOfWork) 被调用，处理第一个Fiber节点。
   • 处理完成后，React会检查 shouldYield()。
     • 如果 shouldYield() 返回 false: 说明当前时间片还有剩余，或者没有更高优先级的任务。nextUnitOfWork 更新为下一个Fiber节点，循环继续。
     • 如果 shouldYield() 返回 true: 说明当前时间片已用尽，或者有更高优先级任务。workLoopConcurrent 停止执行，但 nextUnitOfWork 仍指向未完成的Fiber节点。控制权返回给浏览器。
4. 浏览器空闲: 浏览器在拿到控制权后，可以进行布局、绘制、事件处理等操作。当浏览器再次空闲时（或者下一个 MessageChannel 宏任务被触发），Scheduler会再次调用 workLoopConcurrent。
5. 恢复渲染阶段: workLoopConcurrent 从上次中断的地方 (nextUnitOfWork 指向的节点) 继续执行。这个过程会重复步骤3和4，直到所有的渲染工作（即所有的 performUnitOfWork 调用）都完成。
6. 渲染阶段完成: 当 nextUnitOfWork 最终变为 null 时，表示整个Fiber树的协调工作已经完成，一个完整的 workInProgress 树已经构建完成，其中包含了所有待应用的副作用。
7. 提交阶段 (Commit Phase):
   • 一旦渲染阶段完成，React会进入提交阶段。这个阶段是同步且不可中断的。
   • React遍历 workInProgress 树中所有带有 effectTag 的Fiber节点。
   • 根据 effectTag，React会执行实际的DOM操作（插入、更新、删除）。
   • 执行生命周期方法（componentDidMount、componentDidUpdate、useLayoutEffect）和处理Refs。
   • 将 workInProgress 树设置为当前的 current 树，完成更新。
   • 整个提交阶段必须快速完成，以避免UI阻塞。

通过这种方式，React巧妙地将耗时的渲染工作拆分成无数个小块，并在每个小块之间将控制权交还给浏览器，从而确保了即使在处理复杂UI更新时，用户界面也能保持高度响应。

七、收益与权衡：并发模式的影响

React的并发模式及其 performUnitOfWork 的可中断性带来了显著的收益，但也伴随着一定的权衡。

7.1 收益

1. 极致的UI响应性: 最核心的优势。用户不会再感受到UI卡顿，动画和交互更加流畅。
2. 可中断和可恢复的渲染: 渲染工作可以在任何Fiber节点处理完成后暂停，并在稍后从中断处恢复，极大地提升了用户体验。
3. 优先级调度: 允许React根据任务的重要性来分配CPU时间。例如，用户输入事件（如打字）的更新会优先于不重要的后台数据渲染。
4. 并发更新: 多个更新可以同时进行，低优先级的更新可以在高优先级更新到来时被暂停甚至废弃，从而避免不必要的渲染工作。
5. Suspense: 并发模式是实现 Suspense 的基础。它允许组件在数据尚未准备好时“暂停”渲染，并显示加载指示器，待数据可用后再继续渲染，而不会阻塞整个UI。

7.2 权衡

1. 架构复杂性: Fiber架构和调度器机制比传统的Stack Reconciler复杂得多，理解和调试其内部工作原理需要更深入的知识。
2. 内存开销: 为了支持双缓冲（current 和 workInProgress 树）以及调度器维护任务队列，会引入一定的内存开销。
3. 渲染行为变化: 由于渲染阶段是可中断的，组件的 render 方法（或函数组件的执行）可能会被多次调用，或者在提交前被中断。这要求开发者编写“纯粹”的渲染逻辑，避免在 render 过程中产生副作用，并将副作用集中到 useEffect/useLayoutEffect 或生命周期方法中。
4. 开发心智负担: 虽然React抽象了大部分复杂性，但理解并发模式的工作原理对于编写高性能和无bug的应用仍然很重要，尤其是在处理并发状态更新和 Suspense 时。

八、前瞻：并发模式的未来

performUnitOfWork 和其背后的调度机制是React并发模式的基石。随着React 18的发布，并发特性不再是实验性的，而是被逐步推广。这意味着开发者可以更广泛地利用 startTransition、useDeferredValue 和 Suspense 等API来构建更加响应和流畅的用户界面。

这些API的底层，正是 performUnitOfWork 在 workLoopConcurrent 循环中，结合 shouldYield() 和调度器，精妙地将控制权在JavaScript和浏览器之间进行切换，实现了前所未有的用户体验。

React的这种设计哲学，即通过合作式多任务来解决单线程JavaScript的UI阻塞问题，不仅在前端框架领域树立了新的标杆，也为其他JavaScript应用提供了宝贵的思路。它证明了在有限的资源下，通过精巧的调度和任务分解，仍然可以实现卓越的性能和用户体验。

performUnitOfWork 作为React Fiber协调器的核心原子操作，在每次执行后都与调度器紧密协作，通过判断 shouldYield() 来决定是否暂停工作，将控制权交还给浏览器。这种合作式多任务的调度机制，是React并发模式的基石，彻底改变了前端应用处理复杂更新的方式，显著提升了用户界面的响应性和流畅性。