深入理解 React 可中断渲染：从原理到开发实践React 18 引入的并发模式（Concurrent Mode）

React 18 引入的 并发模式（Concurrent Mode） 是 React 架构的一次重大升级，其核心特性便是 可中断渲染（Interruptible Rendering） 。

这一机制允许 React 在渲染过程中暂停、中止或丢弃正在进行的任务，以便优先处理更高优先级的更新（如用户点击、输入），随后再恢复或重新开始之前的低优先级任务。这与 React 15 及之前版本的 “同步不可中断” 机制形成了鲜明对比，彻底解决了大型应用在复杂计算时的主线程阻塞问题。

1. 核心机制对比：从“Monolithic”到“微任务队列”

🔴 旧机制：同步不可中断 (Sync / Blocking)

在 React 18 之前，一旦 React 开始渲染（Reconciliation 阶段），它就会一口气执行到底，直到生成完整的虚拟 DOM 树并提交到屏幕。

痛点：如果组件树庞大或计算复杂，渲染过程可能耗时数百毫秒甚至数秒。在此期间，主线程被完全占用，用户无法进行任何交互（点击无反应、输入卡顿），导致页面“假死”。
比喻：就像厨师在做一道复杂的菜，必须从头做到底才能端出来。期间即使客人饿了想先吃个面包，厨师也必须把手里的活干完才能去拿面包。

🟢 新机制：可中断渲染 (Concurrent / Interruptible)

在 React 18 的并发模式下，渲染工作被拆分成许多小的 时间片（Time Slices） 。

机制：React 每执行一小段渲染任务，就会检查是否有更高优先级的任务插队。
- 若有高优任务：React 会暂停当前低优先级渲染，保存现场，立即处理高优任务。处理完后，再回来继续或重新渲染。
- 若无高优任务：继续执行下一个时间片。
优势：保证了高优先级交互的绝对流畅，即使后台正在进行海量数据的渲染。
比喻：厨师每切几刀菜就看一眼客人。如果客人招手，立刻放下刀去招呼；回来后继续切。如果客人突然换了想吃的菜，厨师会直接把刚才切了一半的菜扔掉，重新做新的。

2. 技术实现原理：时间切片 (Time Slicing)

React 实现可中断渲染的关键在于将庞大的渲染任务拆解为细粒度的单元：

工作单元拆分 (Fiber)
React 将 Fiber 树（虚拟 DOM 树）的遍历和更新拆分成一个个小的单元。每个 Fiber 节点就是一个独立的工作单元，这是可中断的基础数据结构。
调度器 (Scheduler)
React 内置的调度器利用浏览器的空闲机制（原生 requestIdleCallback 或基于 MessageChannel 的 Polyfill）来协调任务执行。
时间片检查与让出 (Yielding)
- 每次完成一个 Fiber 节点的工作后，React 会检查剩余时间。
- 如果时间片用完（通常约 5ms）或有更紧急任务到来，React 会主动让出主线程控制权，使浏览器能够响应用户事件、动画或网络回调。
- 当浏览器再次空闲时，React 请求下一个时间片继续工作。
状态保存与恢复
由于任务是可中断的，React 必须在内存中精确保存当前渲染进度（通过 Fiber 树上的 workInProgress 指针），以便在中断后能准确恢复现场。

3. 可中断带来的两大核心行为

由于渲染过程不再是一条直线，产生了两个旧版本中不存在的关键行为：

A. 任务抢占 (Preemption)

高优先级更新（如打字）可以打断低优先级更新（如渲染大数据列表）。

场景：用户正在输入搜索框，同时后台正在渲染搜索结果列表。
结果：输入框的响应永远是即时的。列表渲染会被反复打断，直到用户停止输入或列表渲染完成。

B. 任务丢弃 (Dropping / Throwing Away Work)

这是可中断渲染最强大的特性。如果在低优先级任务完成前，状态发生了新的变化，之前未完成的渲染结果将直接作废。

场景：用户快速切换 Tab（A → B → C）。
旧版表现：完整渲染 A → 提交 → 完整渲染 B → 提交 → 完整渲染 C。用户看到页面闪烁，体验卡顿。
新版表现：
1. 开始渲染 Tab A。
2. 用户切到 Tab B → 中断并丢弃 A 的工作，立即渲染 B。
3. 用户切到 Tab C → 中断并丢弃 B 的工作，立即渲染 C。
4. 最终只提交 Tab C 的结果。
收益：用户永远只看到最新的状态，避免了中间无效状态的渲染浪费和视觉闪烁。

4. 实战指南：如何使用并发 API

要启用可中断渲染，必须使用 React 18 提供的并发 API。普通的 root.render() 依然保持同步行为。

核心 API：`startTransition` 与 `useTransition`

通过将某些更新标记为 “过渡更新”（Transition） ，告知 React 这些更新是非紧急的，可以被中断。

import { useState, useTransition } from 'react';

function SearchPage() {
  const [query, setQuery] = useState('');
  const [filteredList, setFilteredList] = useState([]);
  // 开启过渡模式
  const [isPending, startTransition] = useTransition(); 

  // 1. 高优先级更新：直接设置，立即响应
  const handleInputChange = (e) => {
    setQuery(e.target.value); 
  };

  // 2. 低优先级更新：包裹在 startTransition 中
  const handleSearch = (newQuery) => {
    startTransition(() => {
      // 这个渲染过程是可中断的
      // 如果用户在计算过程中再次输入，当前渲染会被丢弃，基于新 query 重新开始
      const result = filterHugeList(newQuery); 
      setFilteredList(result);
    });
  };

  return (
    <>
      <input value={query} onChange={handleInputChange} />
      
      {/* 显示加载状态，仅在过渡挂起时显示 */}
      {isPending && <Spinner />} 
      
      <List items={filteredList} />
    </>
  );
}

代码解析：

setQuery 是紧急的，保证输入框不卡顿。
setFilteredList 被标记为过渡更新。若计算量大，React 会将其拆分。若用户中途再次输入，React 会丢弃当前的列表计算，基于最新的 query 重新计算，确保 UI 始终响应最新操作。

5. 对开发者的深远影响与最佳实践

可中断渲染不仅仅是性能优化，它改变了编写组件的思维方式。以下是必须遵守的新规范：

1. 核心铁律：渲染函数必须是“纯”的 (Pure Functions)

背景：在并发模式下，React 可能会启动一个渲染任务，中途丢弃它，然后基于新状态重新开始。这意味着同一个组件的渲染函数可能会被调用多次，而只有最后一次的结果会被提交。

禁忌：严禁在渲染过程中执行副作用（Side Effects）。

// ❌ 错误示范
let globalCount = 0;
function MyComponent({ data }) {
  globalCount++; // 危险！渲染重试会导致计数混乱
  if (!data.cached) fetchData(); // 危险！可能导致重复网络请求
  return <div>{data.value}</div>;
}

正确做法：所有副作用（数据获取、订阅、DOM 操作、计时器）必须放入 useEffect 或 useLayoutEffect 中。渲染函数只能负责计算和返回 JSX。

2. 警惕“状态撕裂” (Tearing)

风险：由于渲染可暂停，若在渲染过程中外部数据源（如全局 Store、Context）发生变化，可能导致 UI 显示不一致（一部分是旧状态，一部分是新状态）。
解决方案：
- 使用 React 官方推荐的 useSyncExternalStore 钩子来同步外部存储。
- 确保状态管理库（Redux Toolkit, Zustand, Jotai, TanStack Query 等）已更新以支持 Concurrent React。

3. 重构加载体验

新范式：利用 Suspense 和 Transitions 实现细粒度加载。
- 乐观更新：UI 立即响应用户操作，后台数据慢慢加载。
- 原子性切换：在新内容完全准备好之前，保持旧内容可见，避免显示半成品或 Loading 遮罩，直到新内容就绪瞬间切换。

4. 调试与测试的挑战

调试现象：console.log 可能打印多次（因为渲染被重试）；断点调试时可能发现代码执行了但 DOM 未更新（因为那次渲染被丢弃）。
Strict Mode 增强：在开发模式下，React 故意将组件渲染两次（第一次立即丢弃），以帮助开发者提前发现不纯的副作用。
测试调整：
- 使用 @testing-library/react 的异步查询（findByText 而非 getByText）。
- 测试中需包裹 await act(async () => { ... }) 以确保所有过渡更新已刷新。

5. 生态兼容性与类组件限制

第三方库：检查 UI 库和状态管理库是否支持 React 18。依赖同步渲染假设的旧库（特别是直接操作 DOM 的库）可能会行为异常。
类组件 (Class Components) ：虽然仍受支持，但类组件的生命周期本质是同步的，难以优雅处理“暂停”和“恢复”。为了获得并发红利，强烈建议迁移至 Function Components + Hooks。

6. 总结：开发者心态的转变

维度	同步渲染时代 (React 15/16)	可中断渲染时代 (React 18+)
渲染假设	渲染一旦开始，必然完成并提交	渲染随时可能被打断、丢弃或重试
副作用位置	有时混在渲染逻辑中（虽不推荐但能跑）	严禁在渲染中产生副作用，必须严格分离
数据获取	在 `useEffect` 中获取，渲染时读全局变量	推荐 Suspense + `useSyncExternalStore`，避免读取易变全局状态
用户体验	要么全有，要么全无（Loading 遮罩）	细粒度控制，优先响应交互，后台渐进式更新
代码纯度	重要，但不致命	生死攸关，不纯的组件会导致难以追踪的 Bug

💡 核心建议

拥抱 Function Components，严格遵守 Pure Render 原则，将所有副作用移入 useEffect，并采用支持并发模式的生态库。只有这样，你才能安全地享受可中断渲染带来的极致流畅体验，构建适应未来复杂场景的现代 Web 应用。

深入理解 React 可中断渲染：从原理到开发实践