什么是 ‘Concurrent Features’ 的原子性？解析 React 如何保证在渲染中断时屏幕不会显示不完整的 UI

欢迎来到今天的讲座，我们将深入探讨一个在现代前端开发中至关重要，但又常常被误解的概念：’Concurrent Features’ 的原子性，以及 React 如何利用它来确保在渲染中断时，屏幕上不会显示不完整的 UI。作为一名编程专家，我将带您穿梭于 React 内部机制，揭示其并发模式下实现 UI 完整性的精妙之处。

第一章：原子性的核心概念

在计算机科学中，原子性（Atomicity）是事务（Transaction）的一个基本特性，通常与数据库的 ACID (原子性、一致性、隔离性、持久性) 特性联系在一起。一个原子操作要么完全成功执行，要么完全不执行，不存在中间状态。如果一个原子操作在执行过程中失败，它所做的所有修改都将被撤销，系统会回滚到操作开始之前的状态。

为什么原子性在 UI 渲染中如此重要？

想象一下，如果一个复杂的 UI 更新不是原子的，用户可能会看到什么？

1. 不完整的界面： 某些组件更新了，而另一些没有，导致屏幕上出现混乱或破碎的布局。
2. 不一致的数据： UI 显示的数据与实际状态不符，例如，一个列表更新了一半，导致显示的数据项与总数不匹配。
3. 闪烁或跳动： 界面在更新过程中反复变化，给用户带来糟糕的体验。
4. 功能故障： 用户可能尝试与一个不完整的 UI 交互，导致程序崩溃或进入错误状态。

在传统的同步渲染模型中，当一次更新开始时，它会一直运行直到完成，期间会阻塞主线程，导致 UI 冻结。这在某种程度上保证了原子性——要么显示旧状态，要么显示完整的新状态。然而，这种“原子性”是以牺牲用户体验为代价的：长时间的阻塞会让人感觉应用卡顿。

React 的并发特性旨在解决这个问题：允许渲染工作被中断和恢复，从而提高应用的响应性。但中断就意味着渲染过程可能不完整。如何在允许中断的同时，依然保证用户看到的 UI 始终是完整且一致的？这正是今天我们讲座的核心。

第二章：React 的传统渲染机制与挑战

在深入并发特性之前，我们先快速回顾一下 React 16 之前或在非并发模式下的渲染机制。

2.1 传统的同步渲染流程

在 React 的早期版本中，渲染是一个完全同步的过程。当 setState 或 forceUpdate 被调用时，React 会执行以下步骤：

1. 调度更新： 将更新标记到组件上。
2. 协调 (Reconciliation)：
   • 从根组件开始，遍历整个组件树。
   • 为每个组件调用 render 方法，生成新的 React 元素树（即所谓的 Virtual DOM）。
   • 将新的元素树与旧的元素树进行比较，计算出最小的 DOM 操作集合。
3. 提交 (Commit)： 将计算出的 DOM 操作应用到真实的浏览器 DOM 上。

这个过程是“all or nothing”的：一旦协调开始，它就会一口气运行到完成，然后才将所有更改一次性提交到 DOM。整个协调过程都在 JavaScript 主线程上执行。

2.2 Fiber 架构的引入

React 16 引入了 Fiber 架构，这是 React 内部一次重大的重写。Fiber 是对 React 渲染工作单元的重新实现，它将一个组件的渲染工作拆分成可中断的小单元。

Fiber 的核心思想：

• 链表结构： 每个 Fiber 节点代表一个组件实例，并包含指向其父节点、子节点和兄弟节点的指针，形成一个 Fiber 树。
• 可中断性： Fiber 允许 React 在处理组件树时暂停当前工作，稍后再恢复。这通过将工作分解为小的“工作单元”（work unit）来实现，每个工作单元完成后，React 都可以检查是否有更高优先级的任务需要处理。
• 优先级： 每个 Fiber 节点可以有一个优先级，调度器可以根据优先级来决定下一个处理哪个工作单元。
• 双缓冲： React 维护两棵 Fiber 树：一棵是当前屏幕上显示的 Fiber 树 (current tree)，另一棵是在内存中构建的“工作进行中”的 Fiber 树 (workInProgress tree)。

Fiber 架构本身并没有立即带来并发渲染，但它为并发渲染奠定了基础。它使得 React 能够将渲染工作分解成小块，并且能够暂停、恢复和重用这些工作。

2.3 同步渲染带来的挑战

尽管 Fiber 架构提供了可中断性，但在默认的同步模式下，React 仍然会尽可能快地完成所有工作，而不会主动中断。这导致了以下问题：

// 示例：一个可能导致 UI 卡顿的同步渲染场景
import React, { useState, useMemo } from 'react';

// 这是一个计算密集型组件，模拟耗时操作
const SlowComponent = ({ value }) => {
  const startTime = performance.now();
  // 模拟大量计算，阻塞主线程
  let result = 0;
  for (let i = 0; i < 100000000; i++) {
    result += Math.sin(i) * Math.cos(i);
  }
  const endTime = performance.now();
  console.log(`SlowComponent rendered in ${endTime - startTime}ms`);
  return <p>Calculated result: {result.toFixed(2)} - Value: {value}</p>;
};

function App() {
  const [count, setCount] = useState(0);
  const [inputValue, setInputValue] = useState('');

  const displayedCount = useMemo(() => count, [count]);

  const handleInputChange = (e) => {
    setInputValue(e.target.value); // 这个更新是高优先级的（用户输入）
  };

  const handleIncrement = () => {
    setCount(prev => prev + 1); // 这个更新可能优先级较低（内部状态）
  };

  return (
    <div>
      <h1>传统同步渲染示例</h1>
      <button onClick={handleIncrement}>Increment Count: {count}</button>
      <p>
        输入框：
        <input
          type="text"
          value={inputValue}
          onChange={handleInputChange}
          style={{ width: '300px' }}
        />
      </p>
      {/* 这是一个耗时渲染的组件，当 count 变化时会重新渲染 */}
      {/* 在同步模式下，SlowComponent 的渲染会阻塞输入框的响应 */}
      <SlowComponent value={displayedCount} />
      <p>Current Input: {inputValue}</p>
    </div>
  );
}

export default App;

在上述 App 组件中，如果 SlowComponent 渲染时间很长，当 count 发生变化时，SlowComponent 的重新渲染会阻塞主线程。这意味着，即便用户在 SlowComponent 渲染期间尝试在输入框中输入文字，输入框也会无响应，直到 SlowComponent 渲染完成。这导致了严重的 UI 卡顿和糟糕的用户体验。

这就是并发 React 希望解决的核心问题：如何在保持 UI 响应性的同时，处理好这些耗时的渲染任务，并且不让用户看到任何不完整的中间状态。

第三章：并发 React 的诞生与核心思想

并发 React 的目标是让应用感觉更流畅、更响应迅速。它通过引入一套新的调度机制，允许 React 在渲染过程中中断、暂停、恢复和重用工作。

3.1 并发 (Concurrency) vs. 并行 (Parallelism)

在理解并发 React 之前，区分“并发”和“并行”至关重要：

• 并行 (Parallelism)： 指的是同一时间执行多个任务。这通常需要多个 CPU 核心或处理器。例如，一个多核处理器可以同时运行两个独立的线程。
• 并发 (Concurrency)： 指的是能够处理多个任务，即使这些任务在同一时间段内不一定同时执行。它更关注任务的组织和调度，使得在单核处理器上也能给人一种“同时进行”的错觉。任务可以在执行过程中暂停和切换，从而提高系统的响应性。

React 的并发特性是关于“并发”而非“并行”。它利用单线程的 JavaScript 环境，通过时间切片（time slicing）和优先级调度，在不同任务之间快速切换，从而模拟出多个任务同时进行的感知。

3.2 调度器 (Scheduler) 与时间切片

并发 React 的核心是其内部的调度器。这个调度器负责决定何时执行哪个任务，以及任务的优先级。

• 任务优先级： 调度器会为不同的更新赋予不同的优先级。例如，用户输入事件（如键盘输入、点击）通常具有最高优先级，因为它们直接影响用户体验。而一些非紧急的数据展示、动画或者后台计算则可以有较低的优先级。
• 时间切片： 调度器将渲染工作分解成小块，并在每个小块完成后，将控制权交还给浏览器。浏览器可以在这段时间处理高优先级的任务（如用户输入），然后再将控制权交还给 React，让它继续处理渲染工作。如果此时有更高优先级的更新进来，React 甚至可以放弃当前正在进行的低优先级渲染工作，转而处理高优先级任务。

3.3 Lane 模型

React 18 引入了 Lane 模型，这是对 Fiber 架构中优先级系统的进一步细化。Lane 模型允许 React 更细粒度地管理更新的优先级。

• Lanes： 每个更新都被分配到一个或多个“lane”（泳道）。Lanes 是一个 31 位的位掩码，每一位代表一个优先级。
• 优先级分组： 不同的 lanes 可以代表不同的优先级组，例如：
  • SyncLane：同步优先级，最高优先级，不可中断。
  • InputContinuousLane：连续输入优先级，如拖拽、滚动。
  • DefaultLane：默认优先级，如数据获取。
  • TransitionLane：过渡优先级，可中断，最低优先级。
• 批量更新： 具有相同 lane 的更新可以被批量处理。
• 优先级继承： 父组件的更新优先级会传递给子组件。

Lane 模型使得调度器能够更灵活地管理并发更新，确保高优先级的更新能够及时响应，而低优先级的更新则可以在不阻塞 UI 的前提下逐步完成。

3.4 关键 API：useTransition 和 useDeferredValue

为了让开发者能够利用并发特性，React 提供了几个新的 API：

• useTransition / startTransition： 将一个状态更新标记为“过渡”（transition）。过渡更新是可中断的，优先级较低。React 会尽量在不阻塞用户交互的情况下执行这些更新。
  • 当一个过渡更新正在进行时，如果用户触发了高优先级更新（例如输入），React 会暂停过渡更新，优先处理高优先级更新。
  • 用户界面在过渡更新完成之前，会保持在旧的状态，直到新的、完整的状态准备好并被提交。
  • isPending 标志可以用来向用户显示一个加载指示器。
• useDeferredValue： 允许您延迟更新 UI 的一部分，直到一个值变得“稳定”。它类似于 debounce，但它与 useTransition 的区别在于，useDeferredValue 关注的是一个值的“新鲜度”，而 useTransition 关注的是一个状态更新的“紧急程度”。
  • 当源值变化时，useDeferredValue 会立即返回旧值，同时在后台安排一个低优先级的更新来计算并返回新值。
  • 在新的值准备好之前，UI 不会更新，从而避免了卡顿。

代码示例：使用 useTransition 解决输入框卡顿问题

让我们改造一下之前的 App 组件，使用 useTransition 来避免卡顿。

import React, { useState, useTransition, useMemo } from 'react';

// 这是一个计算密集型组件，模拟耗时操作
const SlowComponent = React.memo(({ value }) => { // 使用 React.memo 避免不必要的渲染
  const startTime = performance.now();
  let result = 0;
  for (let i = 0; i < 100000000; i++) {
    result += Math.sin(i) * Math.cos(i);
  }
  const endTime = performance.now();
  console.log(`SlowComponent rendered in ${endTime - startTime}ms with value: ${value}`);
  return <p>Calculated result: {result.toFixed(2)} - Value: {value}</p>;
});

function AppConcurrent() {
  const [count, setCount] = useState(0);
  const [inputValue, setInputValue] = useState('');
  const [displayedCount, setDisplayedCount] = useState(0); // 用于 SlowComponent 的状态

  // useTransition 钩子返回一个 isPending 标志和一个 startTransition 函数
  const [isPending, startTransition] = useTransition();

  const handleInputChange = (e) => {
    // 这个是高优先级的更新，直接更新输入框
    setInputValue(e.target.value);

    // 将更新 displayedCount 的逻辑包装在 startTransition 中
    // 这意味着 displayedCount 的更新是低优先级的，可中断的
    startTransition(() => {
      // 这里的更新可能触发 SlowComponent 渲染，但它不会阻塞主线程
      setDisplayedCount(count); // 这里我们让 displayedCount 总是和 count 同步，但以 transition 方式
    });
  };

  const handleIncrement = () => {
    setCount(prev => prev + 1);
    // 同样，将 displayedCount 的更新也放在 transition 中
    startTransition(() => {
      setDisplayedCount(count + 1); // 注意：这里是 count + 1，因为 setCount 是异步的
    });
  };

  return (
    <div>
      <h1>并发渲染示例 (useTransition)</h1>
      <button onClick={handleIncrement} disabled={isPending}>
        Increment Count: {count} {isPending && '(Updating...)'}
      </button>
      <p>
        输入框：
        <input
          type="text"
          value={inputValue}
          onChange={handleInputChange}
          style={{ width: '300px' }}
        />
      </p>
      {/* 只有当 isPending 为 false 时才显示 SlowComponent 或显示加载状态 */}
      {isPending ? <p>Loading slow component...</p> : <SlowComponent value={displayedCount} />}
      <p>Current Input: {inputValue}</p>
    </div>
  );
}

export default AppConcurrent;

在这个并发版本中：

1. 当 handleInputChange 被调用时，setInputValue 会立即更新输入框，这是高优先级的。
2. startTransition(() => { setDisplayedCount(count); }) 里面的更新被标记为低优先级。如果 SlowComponent 渲染很慢，并且用户继续输入，React 会优先处理 setInputValue 的更新，而暂停或丢弃 setDisplayedCount 的更新，直到主线程空闲下来。
3. isPending 标志允许我们在过渡期间显示一个加载指示器，提升用户体验。
4. 用户在输入框中输入时，不会再感觉到卡顿，因为输入框的更新优先级更高，且 SlowComponent 的渲染被推迟或中断。

第四章：工作中的原子性 – Work-in-Progress (WIP) Tree

现在我们来到了核心问题：当渲染被中断时，React 如何确保屏幕上不会显示不完整的 UI？答案就在于其内部的“工作进行中”树（Work-in-Progress Tree）以及独特的渲染提交机制。

4.1 双缓冲机制的类比

理解 React 的原子性，最好的方式是将其与图形学中的“双缓冲”机制进行类比。

• 在图形渲染中，为了避免画面撕裂和闪烁，通常会使用两个缓冲区：一个“前台缓冲区”（front buffer）当前正在显示给用户，另一个“后台缓冲区”（back buffer）在后台进行绘制。
• 所有的绘制操作都在后台缓冲区进行。当后台缓冲区的内容完全绘制完成且准备好显示时，前台缓冲区和后台缓冲区会进行一次“交换”（swap），将后台缓冲区的内容瞬间切换到屏幕上。
• 用户永远不会看到正在绘制的半成品画面，只会看到完整的旧画面或完整的、最新的画面。

React 的并发渲染机制正是基于类似的“双缓冲”思想。

4.2 current Tree 与 workInProgress Tree

React 内部维护着两棵 Fiber 树：

1. current tree (当前树)： 这棵树代表了当前屏幕上实际显示的 UI 状态。它与真实的 DOM 结构一一对应。
2. workInProgress tree (工作进行中树)： 当有新的更新（setState、useReducer 等）被调度时，React 会从 current tree 克隆一份 workInProgress tree。所有的渲染计算、协调（reconciliation）都在这棵 workInProgress tree 上进行。

关键点：

• 所有的修改（属性、状态、子节点、甚至组件结构的变化）都只发生在 workInProgress tree 上。
• current tree 保持不变，直到 workInProgress tree 完全构建完成，并且所有更新都准备好被提交。

4.3 渲染的两个阶段：Render Phase 与 Commit Phase

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

4.3.1 渲染阶段 (Render Phase / Reconciliation Phase)

• 执行内容： 在这个阶段，React 遍历 workInProgress tree，并执行以下操作：
  • 调用组件的 render 方法（或函数组件体）。
  • 计算新的 Virtual DOM 结构。
  • 比较新旧 Fiber 节点，找出差异。
  • 执行 useState、useReducer、`useContext 等 Hooks。
  • 进行优先级调度，决定哪些组件需要更新。
• 特性：
  • 可中断： 这是关键！渲染阶段的工作可以被暂停、恢复，甚至完全丢弃。如果更高优先级的更新出现，或者时间切片耗尽，React 就可以中断当前渲染工作。
  • 纯净 (Pure)： 为了能够安全地中断和重试，渲染阶段必须是纯净的。这意味着在渲染阶段：
    • 不应该有副作用（side effects），例如直接修改 DOM、发起网络请求、订阅事件等。
    • 多次执行同一个组件的 render 方法或函数组件体，必须产生相同的结果（给定相同的 props 和 state）。
    • 不应该直接修改组件外部的数据。
  • 不影响 UI： 这个阶段的所有操作都发生在内存中的 workInProgress tree 上，不会对当前屏幕上显示的 UI 产生任何影响。用户仍然看到的是 current tree 所代表的旧 UI。

4.3.2 提交阶段 (Commit Phase)

• 执行内容： 当 workInProgress tree 完全构建完成，并且所有计算都已准备就绪时，React 进入提交阶段。在这个阶段，React 会：
  • 将 workInProgress tree 中的所有变更一次性应用到真实的 DOM 上。
  • 执行生命周期方法（如 componentDidMount、componentDidUpdate、componentWillUnmount）和 useEffect、useLayoutEffect 等 Hooks 的回调函数。
  • 更新 ref。
• 特性：
  • 不可中断 (Synchronous)： 提交阶段是完全同步的，不可中断。一旦开始，它必须一口气运行到完成。这是为了确保 UI 更新的原子性。
  • 副作用安全： 所有的副作用（如 DOM 操作、网络请求）都应该在这个阶段执行，或者通过 useEffect / useLayoutEffect 钩子在提交后执行。
  • 原子性： 提交阶段是 React 实现 UI 更新原子性的核心。它确保了用户要么看到旧的、完整的 UI，要么看到新的、完整的 UI，绝不会看到中间的、不完整的状态。

表格：渲染阶段 vs. 提交阶段

特性	渲染阶段 (Render Phase)	提交阶段 (Commit Phase)
执行时机	更新被调度后，在内存中构建 workInProgress tree	workInProgress tree 构建完成后
目的	计算 UI 差异，构建新的 Fiber 树	将变更应用到真实 DOM，执行副作用
可中断性	可中断（Interruptible）	不可中断（Synchronous）
副作用	不允许（必须是纯净函数）	允许（如 DOM 操作、useEffect、生命周期方法）
对 UI 影响	无（在内存中操作，用户看到旧 UI）	直接影响（将新 UI 呈现在屏幕上）
状态	可能暂停、恢复或丢弃	必须一次性完成
原子性	阶段本身非原子，但其结果通过提交阶段实现原子性	核心原子性保证（“All or Nothing”的 UI 切换）

第五章：原子性如何保证 UI 完整性

现在我们把这些机制串联起来，看看 React 如何在并发模式下，即使渲染被中断，也能保证 UI 的完整性和一致性。

5.1 不显示不完整的 UI

这是并发 React 原子性最直接的体现。

1. 工作在后台进行： 所有的渲染计算、组件函数调用、Virtual DOM 比较等耗时操作，都发生在内存中的 workInProgress tree 上。
2. current tree 不受影响： 在整个渲染阶段，屏幕上显示的 current tree 保持完全不变。用户始终看到一个稳定、完整的旧 UI。
3. 原子化提交： 只有当 workInProgress tree 完全构建完成，并且所有变更都已准备好时，React 才进入不可中断的提交阶段。在这个阶段，React 会以极快的速度（通常在几十毫秒内）将 workInProgress tree 中的所有差异应用到真实的 DOM 上。
4. current 指针切换： 在提交阶段的最后，React 会原子性地将根 Fiber 节点上的 current 指针从旧的 Fiber 树（之前的 current tree）切换到新的 Fiber 树（刚刚完成的 workInProgress tree）。新的 workInProgress tree 立即成为了新的 current tree。

这种“先在后台完全准备好，然后一次性切换”的策略，确保了用户永远不会看到一个正在构建中的、半成品的 UI。他们要么看到旧的完整 UI，要么看到新的完整 UI。

5.2 优雅地处理中断和回滚

如果渲染阶段被中断，或者在渲染过程中发生错误，React 会怎么做？

1. 中断： 如果在渲染阶段，调度器决定需要处理更高优先级的任务（例如用户输入），它会暂停当前正在进行的低优先级渲染工作。workInProgress tree 会被暂时挂起。当高优先级任务完成后，调度器可能会决定继续之前的低优先级渲染，或者在某些情况下，如果旧的 workInProgress tree 已经过时（例如，在中断期间又有新的更新到来），它甚至可能直接丢弃之前的工作，从头开始构建一个新的 workInProgress tree。
2. 错误： 如果在渲染阶段，某个组件的 render 方法抛出了一个错误，React 会立即中止当前 workInProgress tree 的构建。它会向上冒泡错误，直到遇到一个 Error Boundary。如果找到了 Error Boundary，React 会丢弃这个失败的 workInProgress tree，并尝试渲染 Error Boundary 的 fallback UI。

在这两种情况下，由于 current tree 始终没有被修改，所以屏幕上显示的 UI 仍然是旧的、完整的、功能正常的 UI。新的、不完整的或有错误的 workInProgress tree 会被简单地抛弃。这保证了即使在渲染失败或中断的情况下，UI 也不会显示出破碎的状态。

5.3 纯净渲染阶段的重要性

渲染阶段必须是纯净的，这是实现原子性和可中断性的基石。

• 幂等性 (Idempotence)： 纯净的渲染函数意味着给定相同的输入（props 和 state），它总是产生相同的输出，并且没有副作用。这使得 React 可以安全地多次调用渲染函数，而不会产生意外。
• 安全重试： 如果渲染被中断，或者 React 决定从头开始重新渲染，由于渲染函数是纯净的，React 可以安全地重新执行它，而无需担心会重复执行副作用或导致不一致。
• 并发安全： 在并发环境中，渲染函数可能会在不同的时间点、以不同的顺序甚至被多个“线程”（尽管 JavaScript 是单线程的，但可以想象为逻辑上的并发执行上下文）调用。纯净的函数可以避免竞态条件和其他并发问题。

因此，像在 render 方法或函数组件体中直接修改 DOM、发起网络请求、或者直接修改组件外部状态等操作都是被严格禁止的，因为它们会破坏渲染阶段的纯净性，从而危及整个并发模型的原子性和稳定性。所有的副作用都必须被推迟到提交阶段，通过 useEffect 或 useLayoutEffect 来处理。

第六章：并发模式下的状态管理与更新

React 的状态管理 (useState, useReducer) 也与并发特性紧密结合，以保证更新的原子性。

6.1 批量更新 (Batching)

React 总是会尝试批量处理状态更新，以减少不必要的重新渲染。在并发模式下，批量处理更加智能。

function Counter() {
  const [count, setCount] = useState(0);
  const [text, setText] = useState('');

  const handleClick = () => {
    // 即使在这里连续调用两次 setState，React 通常也会将它们批量处理成一次渲染
    setCount(c => c + 1);
    setText('Hello');
    // 在并发模式下，这些更新可能被赋予不同的优先级
    // 如果setText是高优先级（比如与用户输入相关），而setCount是低优先级，
    // React会根据调度器来决定如何处理
  };

  return (
    <div>
      <p>Count: {count}</p>
      <p>Text: {text}</p>
      <button onClick={handleClick}>Update All</button>
    </div>
  );
}

在 handleClick 中，setCount 和 setText 会被 React 批量处理。即使它们可能触发不同的 Fiber 节点更新，最终它们也会在同一个提交阶段一起被应用到 DOM 上。这意味着用户不会看到 count 更新了但 text 还没更新的中间状态，反之亦然。所有相关的状态更新都会作为一个原子单元生效。

6.2 startTransition 中的状态更新

当使用 startTransition 包装状态更新时，这些更新会被标记为低优先级。

import React, { useState, useTransition } from 'react';

function SearchInput() {
  const [query, setQuery] = useState('');
  const [displayedQuery, setDisplayedQuery] = useState('');
  const [isPending, startTransition] = useTransition();

  const handleChange = (e) => {
    // 高优先级更新：立即更新输入框内容
    setQuery(e.target.value);

    // 低优先级更新：延迟更新用于搜索或显示的内容
    startTransition(() => {
      setDisplayedQuery(e.target.value);
    });
  };

  return (
    <div>
      <input type="text" value={query} onChange={handleChange} />
      {isPending ? <span>Loading...</span> : null}
      <p>Searching for: {displayedQuery}</p>
      {/* 假设这里有一个基于 displayedQuery 的搜索结果列表 */}
      {/* 这个列表的渲染可能很慢，但在 transition 中，不会阻塞输入 */}
    </div>
  );
}

在这个例子中：

1. setQuery(e.target.value) 是一个同步的、高优先级的更新，它会立即更新输入框的实际值。
2. setDisplayedQuery(e.target.value) 被包裹在 startTransition 中，因此它是一个低优先级的、可中断的更新。

如果 displayedQuery 的更新触发了一个耗时的渲染，而用户在此期间继续输入：

• query 会立即更新，保持输入框的响应性。
• displayedQuery 相关的渲染工作可能会被中断或延迟。isPending 会变为 true。
• 用户看到的 displayedQuery 值会暂时停留在旧值，直到低优先级的渲染工作完全完成，并被原子性地提交到 DOM。
• 在任何时候，用户都不会看到一个 query 是新值但 displayedQuery 是旧值的“半更新”状态，因为 displayedQuery 相关的 UI 更新将作为整体被提交。

这进一步强化了原子性：即使一个组件的两个状态更新被赋予了不同的优先级，它们的最终效果仍然是原子地应用到 UI 上，只是高优先级的更新会更快地开始并完成其相关的渲染。低优先级的更新会在后台默默进行，直到准备好，然后才被原子地提交。

第七章：异常处理与错误边界

React 的错误边界（Error Boundaries）在并发渲染的原子性保证中也扮演了重要角色。

错误边界是一种 React 组件，它可以捕获其子组件树中 JavaScript 错误，记录这些错误，并显示一个备用 UI，而不是使整个组件树崩溃。

当在并发模式下发生错误时：

1. 渲染阶段的错误： 如果在渲染阶段（例如，在 render 方法或函数组件执行时）发生错误，React 会中止当前 workInProgress tree 的构建。它会向上遍历 Fiber 树，寻找最近的错误边界。一旦找到，它会丢弃所有失败的 workInProgress 树，然后调度错误边界的 fallback UI。由于 current tree 仍然是完整的，所以用户看到的仍然是旧的、完整的 UI，直到错误边界的 fallback UI 被原子地提交。
2. 提交阶段的错误： 提交阶段是同步的，理论上不应该有应用层面的错误（因为渲染阶段是纯净的，副作用都在提交后执行）。如果提交阶段的某些副作用（如 useEffect 中的代码）抛出错误，React 也会尝试通过错误边界来捕获。

核心思想是：无论错误发生在渲染的哪个阶段，React 都会确保用户不会看到一个破碎或不完整的 UI。它会回滚到上一个稳定的状态（current tree），或者显示一个预设的 fallback UI，所有这些都以原子的方式进行。

第八章：实际应用与最佳实践

理解了并发 React 的原子性原理，我们可以在实际开发中更好地利用它。

8.1 何时使用 useTransition 和 useDeferredValue

• useTransition：
  • 当一个状态更新会导致 UI 渲染变得缓慢，但这个更新不是用户交互的直接反馈（例如，搜索结果列表的更新，而不是搜索框本身的更新）。
  • 当您希望在后台进行耗时更新的同时，保持 UI 的响应性，并能够显示加载状态。
  • 例如：筛选列表、生成图表、加载复杂数据。
• useDeferredValue：
  • 当您有一个值，它的变化可能导致昂贵的重新渲染，但您希望延迟这些昂贵的更新，直到该值稳定下来。
  • 它常用于将一个快速变化的值（如输入框的值）“去抖”到一个更稳定的值，用于更昂贵的计算或渲染。
  • 例如：实时搜索框，但搜索结果的显示有延迟；大型数据表格的筛选。

8.2 避免常见陷阱

• 渲染函数的纯净性： 这是并发模式下最重要也是最容易犯错的地方。
  • 不要在组件函数体或 render 方法中执行副作用： 避免直接修改 DOM、发起网络请求、调用 setTimeout / setInterval 等。所有副作用都应该通过 useEffect、useLayoutEffect 或事件处理器来管理。
  • 不要在渲染中修改外部可变状态： 这会导致不可预测的行为和竞态条件。
• 过度使用并发： 并非所有更新都需要并发。对于快速、轻量级的更新，同步模式通常足够好，甚至可能更快（因为少了调度的开销）。仅在您遇到明显的性能瓶颈或需要改善用户体验时才引入并发特性。
• 理解 isPending： 确保您正确使用 isPending 来向用户提供反馈。没有反馈的延迟更新可能让用户感到应用无响应。
• 测试并发行为： 模拟慢渲染和高优先级中断来测试您的并发组件，确保它们在各种场景下都能按预期工作。

8.3 性能考量

并发 React 的引入旨在提高用户体验，而不是单纯地加快渲染速度。在某些情况下，引入并发特性可能会增加一些内部开销（例如，维护两棵 Fiber 树、调度器的工作）。然而，这些开销通常是值得的，因为它们换来了更流畅、更响应迅速的用户界面。

通过避免不必要的渲染（例如使用 React.memo、useMemo、useCallback），您可以最大化并发特性的优势，并确保您的应用高效运行。

第九章：挑战与未来展望

并发 React 带来了巨大的优势，但也伴随着一定的学习曲线和复杂性。对于大多数开发者而言，React 已经将大部分复杂的调度和原子性保证抽象化了，我们只需要理解 useTransition 和 useDeferredValue 的语义。

然而，对于库作者和需要深度优化的应用，理解其内部机制变得更加重要。如何确保第三方库在并发模式下表现良好，如何调试复杂的并发交互，都是需要不断探索的领域。

React 团队仍在不断完善并发特性，未来的版本可能会带来更强大的调度能力、更细粒度的控制，以及更友好的调试工具。随着 Web 应用变得越来越复杂，对高性能和高响应性的需求将持续增长，并发 React 无疑是应对这些挑战的关键一步。

原子性是构建可靠系统的基石。在 React 的并发世界里，通过巧妙地运用 Work-in-Progress Tree 和严格区分渲染与提交阶段，React 成功地在追求极致响应性的同时，坚守了 UI 渲染的原子性原则，确保了用户始终看到一个完整、一致且愉悦的交互界面。