React 架构中的冷热路径分离：分析 React 源码中为了处理万级节点而采取的代码分段加载与缓存策略

各位下午好，欢迎来到今天的“React 架构深度解剖课”。

我是你们的讲师，一个在 React 源码里摸爬滚打多年，头发比你们写的 useEffect 还要少的资深专家。今天我们不讲 API，不讲 Hooks 的花哨用法，我们来讲点“硬菜”。

今天的主题是：《当 React 遇到一万条数据：冷热路径分离与代码分段加载的源码揭秘》。

准备好了吗？让我们把咖啡杯放下，把键盘敲响，我们要开始拆解 React 这个庞然大物的内裤了。

第一部分：万级节点的“渲染地狱”

想象一下，你是一个前端工程师，你的老板（或者产品经理）拍着桌子说：“老板，这个列表有 10,000 条数据，能不能展示出来？”

你看着屏幕，心里想的是：“10,000 个 <li>？如果我用 map 循环，那不是要渲染 10,000 个 DOM 节点？浏览器会当场去世的。”

在旧版本的 React（React 15 及以前）里，这确实是地狱。React 是同步的。一旦你调用 render，它就像一辆失控的卡车，轰隆隆地冲过去，直到它建完整个树，或者直到浏览器崩溃。

同步渲染的痛点：

1. 主线程阻塞： JS 是单线程的。渲染 DOM 是昂贵的。如果你要在 16ms（一帧）内算完 10,000 个节点的 diff，还要算完所有副作用，那你还得顺便算个微积分。
2. 交互卡顿： 用户点击了一下按钮，结果整个页面像死机了一样，要等 3 秒钟才动一下。用户会以为你的网站崩了。

所以，React 必须进化。进化方向只有一个：把繁重的工作扔出去，把轻量级的工作留在这个线程。

第二部分：Fiber 架构——React 的“分身术”

为了解决这个问题，React 团队搞出了 Fiber 架构。Fiber 是什么？你可以把它想象成 React 的“工作单元”，或者说，是一个可中断的函数调用栈。

在 Fiber 之前，React 是一个巨大的函数 render()。在 Fiber 之后，React 变成了一个调度器，它把树拆成了一个个 Fiber 节点。

// 源码级别的伪代码：Fiber 节点结构
function FiberNode(props, type, key) {
  // 核心属性
  this.tag = tag; // 标记是 FunctionComponent, ClassComponent 还是 HostComponent
  this.key = key;
  this.type = type; // 组件类型，比如 'div', 'span'
  this.stateNode = null; // 实例，比如 DOM 元素

  // 指针：这就像是一个人的“前女友”和“现任女友”
  this.return = null; // 父节点
  this.child = null;  // 第一个子节点
  this.sibling = null; // 下一个兄弟节点

  // 状态
  this.pendingProps = props; // 待更新的属性
  this.memoizedProps = props; // 缓存的属性（上次渲染用的）
  this.updateQueue = null; // 更新队列

  // 重要：工作单元的“当前状态”和“待处理状态”
  this.alternate = null; // 这个非常重要，下面细说
}

看到 alternate 了吗？这就是冷热路径分离的物理基础。

第三部分：冷热路径的哲学

在 React 源码中，我们通常把渲染过程分为两个阶段：

1. Reconciliation（协调阶段）： 这是冷路径。它是异步的，负责计算“我们要做什么”。它不直接操作 DOM，它只负责计算，计算完之后告诉调度器“好了，我要改这里，改那里”。
2. Commit（提交阶段）： 这是热路径。它是同步的，负责“真的去改 DOM”。一旦进入这个阶段，React 就会一股脑地把所有变更提交到浏览器。

为什么这么分？
因为协调阶段太重了！万级节点，意味着要遍历 10,000 次，计算 Diff 算法，计算副作用。如果这些都在主线程同步跑，页面就卡死了。

所以，React 的策略是：把协调阶段切碎，切成一个个微小的任务，利用浏览器的 requestIdleCallback（空闲时间）去跑。

// 源码级别的调度逻辑（简化版）
function workLoop(deadline) {
  // 只要浏览器有空闲时间，就一直跑
  while (deadline.timeRemaining() > 0 && workInProgress) {
    performUnitOfWork(workInProgress); // 执行一个工作单元
  }

  // 如果没时间了，或者没活干了，就挂起，等下次空闲
  if (workInProgress) {
    scheduleCallback(IdlePriority, workLoop);
  } else {
    // 全部搞定，进入热路径（提交阶段）
    commitRoot();
  }
}

这就是冷热分离的第一层含义：计算（冷） vs 渲染（热）。

第四部分：双缓冲与节点复用

现在，我们有了 Fiber 节点，也有了异步调度。接下来，我们要解决另一个问题：内存开销。

如果每次渲染都创建 10,000 个新节点，GC（垃圾回收）会报警，性能会直线下降。React 是怎么做的？克隆。

React 使用了双缓冲技术。你可以把它想象成一个舞台剧。

• Current Fiber Tree（当前树）： 这是已经展示给用户看的树，是热路径的产物。
• Work-in-Progress Fiber Tree（工作树）： 这是正在构建的树，是冷路径的产物。

React 不会销毁 Current 树，而是复用它的节点。

// 源码逻辑：如何复用节点
function reconcileChildren(
  workInProgress, 
  current, 
  nextChildren
) {
  if (current !== null) {
    // 热路径：如果父节点已经存在（比如用户没删掉这个 div）
    // 我们就不创建新的，而是复用旧的节点，只更新它的属性

    // 1. 复用 DOM 节点
    workInProgress.stateNode = current.stateNode;

    // 2. 复用 Fiber 节点本身
    workInProgress.alternate = current; // 建立双向链接
    current.alternate = workInProgress;

    // 3. 复用子节点（递归）
    reconcileChildren(workInProgress.child, current.child, nextChildren);
  } else {
    // 冷路径：如果是新节点（比如第一次渲染，或者父节点被删了）
    // 我们才创建新的 Fiber 节点
    workInProgress.child = createChildFiber(nextChildren);
  }
}

这段代码极其关键。它解释了为什么 React 即使在处理万级节点时，依然能保持相对流畅。它没有“推倒重来”，它只是“微调”。

第五部分：代码分段加载

好，现在我们解决了“渲染树太复杂”的问题，但还有一个问题：代码包太大了。

如果你在 React 应用里引入了 10,000 个不同的组件（比如每个组件都是一个页面，或者每个列表项都是一个复杂的卡片），你不能一次性把所有代码都下载下来。

这就需要代码分割。React 16.6 引入了 React.lazy 和 Suspense。

1. 懒加载组件

React.lazy 允许你动态导入一个组件。这就像是在餐厅点菜，你不需要把菜单上所有菜都点一遍，你想吃的时候再喊服务员。

// 源码逻辑：动态导入的包装器
const HeavyComponent = React.lazy(() => import('./HeavyComponent'));

function App() {
  return (
    <div>
      <h1>欢迎</h1>
      <Suspense fallback={<div>加载中...</div>}>
        <HeavyComponent />
      </Suspense>
    </div>
  );
}

源码层面发生了什么？
当你调用 import('./HeavyComponent') 时，浏览器会发起一个网络请求，下载那个 .js 文件块。这个块里只包含 HeavyComponent 的代码。主线程在等待这个块加载完成之前，可以继续去处理其他的冷路径任务。

2. 路由级别的分割

对于万级节点，通常我们不会每个节点都懒加载，那样网络请求太多。我们通常是在路由级别做分割。

// 使用 React Router v6
import { BrowserRouter, Routes, Route } from 'react-router-dom';

// 这些组件只有在路由匹配到时才会加载
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Analytics = lazy(() => import('./pages/Analytics'));
const Settings = lazy(() => import('./pages/Settings'));

function AppRouter() {
  return (
    <Suspense fallback={<PageLoader />}>
      <Routes>
        <Route path="/" element={<Dashboard />} />
        <Route path="/analytics" element={<Analytics />} />
        <Route path="/settings" element={<Settings />} />
      </Routes>
    </Suspense>
  );
}

第六部分：缓存策略——记忆化

在处理万级列表时，还有一个痛点：子组件的重复计算。

假设你的列表项是一个复杂的组件，里面有大量的 useMemo 或者昂贵的计算。如果父组件重新渲染了，React 默认会递归地重新渲染所有子组件，哪怕它们的 props 没变。

这时候，我们就需要手动介入，使用缓存策略。

1. useMemo 与 useCallback

这是 React 提供给我们的“冷热分离”工具。

// 场景：一个包含 10000 个列表项的组件
function HugeList() {
  const items = generateHugeData(); // 假设生成 10000 个对象

  // 错误示范：每次渲染都重新计算这个数组
  // const expensiveItems = items.map(item => transform(item)); 

  // 正确示范：只有当 items 变化时才计算
  const expensiveItems = useMemo(() => {
    console.log("计算开始了，这很慢...");
    return items.map(item => transform(item));
  }, [items]); // 依赖项

  return (
    <ul>
      {expensiveItems.map(item => (
        <ListItem key={item.id} data={item} /> 
      ))}
    </ul>
  );
}

function ListItem({ data }) {
  // 正确示范：缓存回调函数，避免子组件不必要的重渲染
  const handleClick = useCallback(() => {
    console.log("Clicked", data.id);
  }, [data.id]); // 只有 id 变了才变这个函数

  return <li onClick={handleClick}>{data.text}</li>;
}

源码层面的原理：
useMemo 在源码里做的事情很简单：它维护一个 Map 或者一个 WeakMap，记录输入和输出的关系。如果输入没变，它直接返回缓存的结果，跳过计算逻辑。

这就像是把计算结果存进了冰箱。每次打开冰箱（渲染），先看看有没有现成的菜，有就直接吃，不用再炒了。

2. React.memo

这是对组件级别的缓存。

// 源码：React.memo 的实现原理（伪代码）
function memo(Component, compare) {
  return function MemoizedComponent(props) {
    // 这里其实并没有直接调用 Component(props)
    // 而是调用了一个叫 ReactCurrentDispatcher.current.memoizedState
    // 真正的 Component 会在 Commit 阶段或者某个特定的时机被调用
    // 关键在于 compare 函数，它决定了要不要更新
    return Component(props); 
  };
}

第七部分：源码深扒——Reconciler 的分片处理

让我们更深入一点，看看 React 是如何在源码里真正实现“万级节点不卡顿”的。这是最硬核的部分。

1. 调度器的介入

React 内部有一个调度器，它负责在主线程空闲时执行任务。

// 源码：调度器核心逻辑
function scheduleWork() {
  // 如果当前没有在执行任务，或者任务优先级很高
  if (!isWorking || nextPriorityLevel > currentPriorityLevel) {
    // 请求浏览器在空闲时执行 workLoop
    requestIdleCallback(workLoop);
  }
}

function workLoop() {
  // 只要还有任务，或者还有时间，就一直跑
  while (nextUnitOfWork) {
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }
  // 没任务了，提交
  if (!nextUnitOfWork) {
    commitRoot();
  }
}

2. performUnitOfWork —— 单元格的“搬砖”

这个函数是核心。它每次只处理一个 Fiber 节点。

function performUnitOfWork(fiber) {
  // 1. 处理当前节点（可能是计算 Diff，可能是创建 DOM）
  // 比如：如果这是 HostComponent，就创建 DOM 节点
  // 如果这是 FunctionComponent，就调用组件函数
  beginWork(fiber);

  // 2. 如果有子节点，处理子节点
  if (fiber.child) {
    return fiber.child;
  }

  // 3. 如果没有子节点，处理兄弟节点
  let nextFiber = fiber;
  while (nextFiber) {
    completeWork(nextFiber); // 完成当前节点的收尾工作（比如副作用）

    if (nextFiber.sibling) {
      return nextFiber.sibling; // 返回下一个兄弟节点
    }

    nextFiber = nextFiber.return; // 回到父节点
  }

  // 4. 没有兄弟了，也没有父节点了，说明整个树遍历完了
  return null;
}

这就是“分片”的精髓。React 每次只处理一个节点。处理完一个，就暂停一下，把控制权还给浏览器（让浏览器渲染一下当前已经处理好的 DOM，让用户看到一点进度），然后等下一帧再继续。

对于 10,000 个节点，React 不会一次性把它们全处理完，而是处理 100 个，停一下，处理 100 个，停一下。这样主线程就不会长时间被占用，界面就不会卡死。

第八部分：虚拟列表与冷热分离的极致

虽然 React 的 Fiber 架构已经很强了，但如果真的有 10,000 个节点，哪怕是分片处理，DOM 节点开了一万个，浏览器渲染层也会扛不住。

这时候，我们就需要虚拟列表。

虚拟列表的核心思想是：只渲染可视区域内的节点，以及视口上下各缓冲几个节点。

// 虚拟列表组件的伪代码
function VirtualList({ totalItems, itemHeight, renderItem }) {
  const [scrollTop, setScrollTop] = useState(0);
  const containerRef = useRef(null);

  // 计算可视区域能容纳多少个
  const visibleCount = Math.ceil(containerHeight / itemHeight);

  // 计算起始索引
  const startIndex = Math.floor(scrollTop / itemHeight);
  const endIndex = startIndex + visibleCount;

  // 只渲染这部分！
  const visibleItems = useMemo(() => {
    return Array.from({ length: endIndex - startIndex + 1 }, (_, i) => {
      const index = startIndex + i;
      return renderItem({ index, style: { height: itemHeight } });
    });
  }, [startIndex, endIndex, renderItem]);

  return (
    <div 
      ref={containerRef} 
      onScroll={(e) => setScrollTop(e.target.scrollTop)}
      style={{ height: containerHeight, overflow: 'auto' }}
    >
      {/* 占位符，撑开高度 */}
      <div style={{ height: totalItems * itemHeight }}></div>
      {/* 真正的内容 */}
      <div style={{ transform: `translateY(${startIndex * itemHeight}px)` }}>
        {visibleItems}
      </div>
    </div>
  );
}

虚拟列表与 React 架构的冷热分离：

• 冷路径： 当你滚动列表时，计算 startIndex 和 endIndex。这很快。
• 热路径： 只有当 startIndex 变化时，React 才会重新计算并渲染新的 DOM 节点。大部分时候，用户滚动时，startIndex 是固定的，DOM 节点是不变的，所以性能极好。

第九部分：总结——架构师的思维

好了，让我们总结一下 React 是如何通过冷热路径分离来搞定万级节点的。

1. Fiber 架构（宏观）： 把同步渲染变成了异步的、可中断的任务调度。这是基础。
2. 双缓冲（微观）： 复用节点，而不是销毁重建。这节省了内存和计算。
3. 调度器（时间切片）： 利用 requestIdleCallback，把 10,000 个节点的处理工作切碎，分摊到每一帧。这是解决卡顿的关键。
4. 代码分割（资源）： 用 React.lazy 和路由懒加载，把庞大的 JS 包切碎，按需下载。这是解决首屏加载慢的关键。
5. Memoization（缓存）： 用 useMemo 和 React.memo，避免不必要的计算和重渲染。这是解决局部性能问题的关键。

给你的建议：

当你面对一个“万级节点”或者“大数据量”需求时，不要一上来就写代码。

1. 先画图： 你的数据流是什么？是树形结构？是列表？还是图？
2. 找冷热： 哪些计算是昂贵的（冷路径）？哪些是频繁触发的（热路径）？
3. 用工具： 虚拟列表是必须的。React.memo 是好用的。Lazy Loading 是标配。

记住，React 的哲学不是“不惜一切代价把所有东西都算出来”，而是“聪明地计算，在合适的时间做合适的事”。

这就是今天的讲座。希望你们以后写代码时，能像 React 源码一样，从容不迫，分秒必争。现在，去优化你的那个 10,000 条数据的列表吧，别让它成为你职业生涯的黑历史！

下课！