React 架构演进：从 Stack 到 Fiber 的哲学转变

各位同学，大家好。

欢迎来到今天的“前端架构演进史”特别讲座。我是你们的老朋友，一个在代码堆里摸爬滚打了十年的“老油条”。

今天我们不聊怎么写 useEffect，也不聊怎么封装 axios，我们要聊的是 React 的灵魂——它的心脏是怎么跳动的。具体来说，我们要聊聊 React 是如何从一个“固执的暴君”，进化成一个“温文尔雅的绅士”的。

这个话题有点硬核，但我保证，我会用最通俗的大白话，甚至一点幽默感，带你们穿越回 2013 年，看看那个时代的 React 是怎么工作的，又是怎么被逼疯的，最后看看 Fiber 是如何拯救世界的。

准备好了吗？我们开始吧。

---

第一部分：Stack Reconciler 的“暴君”哲学

在 React 15 时代，React 的核心算法叫做 Stack Reconciler。听听这个名字，“栈”。这本身就暗示了它的性格——固执、死板、一条道走到黑。

1.1 递归：最原始的暴力美学

在 React 15 之前，React 的渲染逻辑是基于递归的。

想象一下，你是一个木匠，你的面前有一张复杂的桌子（React 的 Virtual DOM 树）。Stack Reconciler 的逻辑是这样的：你拿起锯子，从最顶端的桌腿开始锯。如果你发现这根桌腿需要修，你就进去修；修完这根，你接着锯下一根；锯完这根，你发现这根桌腿的横档也需要修，你再次递归进去。

在这个过程中，你的大脑（主线程）必须全神贯注，不能干别的。一旦你开始锯，除非你把整张桌子锯完，否则你不能停。这就是递归的本质：原子性。

让我们来看看这段伪代码，感受一下当年 React 的“暴行”：

// 这是一个极其简化的 Stack Reconciler 逻辑
function reconcileChildren(current, workInProgress, element) {
    // 1. 获取当前节点的子节点
    const nextChildren = element.props.children;

    // 2. 如果当前节点存在，就进行比对（Diff 算法）
    if (current) {
        // 这里有一大堆复杂的逻辑，用来判断是更新还是删除
        // 为了演示，我们假设只是遍历
        reconcileChildren(current, workInProgress, nextChildren[0]);
        reconcileChildren(current, workInProgress, nextChildren[1]);
    } else {
        // 3. 如果不存在，就创建
        workInProgress.type = nextChildren.type;
        workInProgress.stateNode = document.createElement(nextChildren.type);
        reconcileChildren(null, workInProgress, nextChildren[0]);
        reconcileChildren(null, workInProgress, nextChildren[1]);
    }
}

// 渲染入口
function render(element, container) {
    const dom = document.createElement(element.type);
    container.appendChild(dom);

    // 疯狂的递归调用
    reconcileChildren(null, dom, element.props.children);
}

看到了吗？这就是 reconcileChildren 递归地调用自己。对于浏览器来说，这就是一个阻塞式的任务。

1.2 阻塞的代价：UI 的“假死”

如果这是一张简单的桌子，那没问题。但如果你要渲染 10,000 个列表项呢？或者渲染一个极其复杂的组件树，里面嵌套了 50 层嵌套的 div？

这时候，递归调用栈会瞬间被填满。JavaScript 的引擎（V8 或 SpiderMonkey）在执行递归时，需要维护一个巨大的调用栈（Call Stack）。这个栈一旦满了，浏览器就会报警：“警告：脚本运行时间过长，页面可能无响应。”

用户体验瞬间崩塌。你的点击事件被阻塞，滚动条被冻结，整个页面就像一潭死水。用户只能盯着那个转圈的加载图标，心里默念：“React，你大爷的，你快点啊！”

Stack Reconciler 的哲学是：“只要我还没算完，你就别想动，别想点击，别想滚动，给我老老实实等着！”

这就是当年的痛点。

---

第二部分：Fiber 的诞生——从“暴力”到“分治”

React 团队意识到，这种“原子性”的递归是不可持续的。他们需要一种新的哲学：可中断性。

于是，在 React 16 中，他们引入了 Fiber Reconciler。

2.1 核心概念：把“树”变成“链表”

Stack Reconciler 是基于调用栈的，它是隐式的。而 Fiber 是基于数据结构的，它是显式的。

Fiber 的核心思想是：将庞大的渲染任务拆解成无数个微小的“工作单元”。

怎么拆？怎么存？React 团队做了一个极其聪明的决定：把 Virtual DOM 树，改造成双向链表。

在 Stack Reconciler 里，父子关系是通过函数调用的栈帧隐式传递的。而在 Fiber 里，每个节点都是一个对象，这个对象里明确地记录了它的“父母”和“孩子”。

每个 Fiber 节点的结构大概是这样的（简化版）：

class FiberNode {
  // 当前节点的类型
  tag: number;

  // 父节点（FiberNode）
  return: FiberNode | null;

  // 第一个子节点
  child: FiberNode | null;

  // 兄弟节点（用于遍历同层级的节点）
  sibling: FiberNode | null;

  // 节点的具体内容
  type: any;
  stateNode: any;

  // 更新相关的数据
  pendingProps: any;
  memoizedProps: any;

  // ... 还有很多属性
}

请注意 child 和 sibling。在 Fiber 里，遍历 DOM 树不再是函数调用栈的压栈出栈，而是指针的移动。

2.2 “切片”的艺术

现在，我们不再是“一口气把整张桌子锯完”，而是变成了“拿着锯子，锯一下，停一下，看看老板（浏览器）有没有别的事让你做”。

这就是 Time Slicing（时间切片）。

React 利用浏览器的 requestIdleCallback（或者更低版本的 MessageChannel）机制。这个 API 允许你在浏览器主线程空闲的时候执行任务。

React 的 workLoop 函数大概是这么个意思：

// Fiber Reconciler 的核心循环
function workLoop(deadline) {
  // 只要浏览器还没忙死，或者我们还有任务没做完
  while (deadline.timeRemaining() > 0 && workInProgress) {
    // 1. 执行一个工作单元
    performUnitOfWork(workInProgress);

    // 2. 移动指针，指向下一个兄弟节点，或者下一个子节点
    workInProgress = workInProgress.next;
  }

  // 3. 如果没做完，但浏览器也不忙了，就挂起任务，把控制权还给浏览器
  // 等浏览器空闲了，再回来继续
  if (workInProgress) {
    requestIdleCallback(workLoop);
  } else {
    // 所有任务做完，提交到 DOM
    commitRoot();
  }
}

function performUnitOfWork(fiber) {
  // 这里就是核心的 Diff 逻辑
  // 创建子节点
  if (!fiber.child) {
    fiber.child = createChild(fiber);
  }

  // 处理副作用（如挂载 DOM）
  if (fiber.effectTag) {
    commitWork(fiber);
  }

  // 如果有兄弟节点，去处理兄弟节点
  if (fiber.sibling) {
    return fiber.sibling;
  }

  // 没兄弟了，回退到父节点
  return fiber.return;
}

哲学的转变：

Stack Reconciler 是同步的。你给我一个 setState，我就把你全家老小都给我算一遍，算完了再给你回话。

Fiber 是异步的。你给我一个 setState，我先算个 5ms，然后说“老板，我累了，歇会儿，你先滚去处理用户的点击事件”。等用户点完了，我再回来接着算。

---

第三部分：Fiber 的“哲学”内核

为什么叫 Fiber？Fiber 是“纤维”的意思。它的本质就是微任务。React 把宏大的渲染任务，分解成了无数根细小的纤维。

3.1 优先级的引入

Stack Reconciler 的另一个问题是它不分青红皂白。无论你是点击了一个按钮，还是更新了一个背景颜色，React 都会用同样的速度、同样的优先级去处理它们。

在 Fiber 架构下，引入了优先级队列。

React 内部定义了各种优先级：

• Urgent Updates（紧急更新）： 点击、输入、按键。这些必须马上响应。
• Continuous Updates（持续更新）： 动画、滚动。
• Background Updates（背景更新）： 更新日志、分析数据、非关键数据的更新。

代码逻辑大概是这样的：

// 模拟优先级调度
function scheduleUpdate(root, update) {
  // 1. 计算这个更新的优先级
  const priority = calculatePriority(update);

  // 2. 把更新放入队列
  // 如果当前正在执行的任务优先级比这个低，那么打断当前任务
  if (priority > currentPriority) {
    interruptCurrentWork();
  }

  // 3. 安排任务
  requestWork(root, priority);
}

场景模拟：
用户点击了一个按钮，触发了 setState({ count: 1 })，这是一个紧急更新。同时，后台代码也在尝试更新一个统计数字。
Fiber 调度器一看：“哎呀，用户点击了，这事儿得先办！”于是它可能会暂停后台的更新，优先渲染按钮的点击反馈。

这就是响应式的体现。UI 必须对用户的输入做出即时反馈。

3.2 双缓冲技术

在 Stack Reconciler 里，我们是在原树的基础上进行修改。而在 Fiber 里，为了性能，React 使用了双缓冲技术。

• Current Fiber Tree： 这是已经渲染在屏幕上的那棵树。
• WorkInProgress Fiber Tree： 这是 React 正在构建的那棵树，是 Current 的副本。

React 的工作流程是这样的：

1. 开始渲染时，Current 变成 workInProgress 的 alternate。
2. React 在内存中构建新的 WorkInProgress 树。
3. 构建完成后，WorkInProgress 变成新的 Current，旧的 Current 被垃圾回收。

这个过程就像电影拍摄。你有一张已经拍好的底片（Current），你正在拍新的底片（WorkInProgress）。拍完后，直接换底片，旧的扔掉。观众（用户）根本感觉不到中间的过渡过程，因为切换是瞬间完成的。

---

第四部分：Effect 链表与 Hooks 的羁绊

React 16 引入 Fiber 后，为了支持 Hooks，又增加了一个很酷的数据结构：Effect List（副作用链表）。

我们知道，Hooks 的规则是：在每次渲染时，Hooks 的调用顺序必须一致。比如 useState 必须在 useEffect 之前调用。

在 Stack Reconciler 时代，这很难实现，因为渲染是递归的，Hook 的状态是绑定在 Fiber 节点上的。但在 Fiber 时代，因为我们是链表遍历，所以 React 可以很容易地把所有带有副作用的 Fiber 节点串联起来。

每个 Fiber 节点里都有一个 memoizedState 指针，它指向了这个节点上所有的 Hooks 状态。

class FiberNode {
  // ... 其他属性

  // 指向当前节点上所有的 Hooks 状态
  memoizedState: Hook | null;

  // 指向下一个需要执行副作用的节点
  nextEffect: FiberNode | null;
}

// 构建副作用链表
function linkEffects(first, last) {
  if (first) {
    if (last) {
      first.nextEffect = last;
    }
  }
}

这意味着，React 可以遍历这个链表，按照顺序执行 useEffect、useLayoutEffect 或者 useInsertionEffect。这保证了 Hooks 的“顺序一致性”在内存层面得到了严格的保证。

代码示例：Effect 链表的构建

function completeWork(current, workInProgress) {
  const nextEffects = [];

  // 遍历子节点
  let child = workInProgress.child;
  while (child) {
    // 如果这个节点有副作用
    if (child.effectTag) {
      // 把它加入副作用链表
      nextEffects.push(child);
    }
    child = child.sibling;
  }

  // 将链表挂载到父节点上
  workInProgress.nextEffect = nextEffects[0];
  let prev = workInProgress;
  for (let i = 1; i < nextEffects.length; i++) {
    prev.nextEffect = nextEffects[i];
    prev = nextEffects[i];
  }
  prev.nextEffect = null;
}

这就是为什么 Hooks 在 React 16+ 里运行得如此丝滑，而早期的 Stack Reconciler 实现很难优雅地支持 Hooks 的原因。Fiber 的链表结构天然契合 Hooks 的状态管理。

---

第五部分：深入解析——为什么 Fiber 如此复杂？

你可能会问：“老哥，既然 Fiber 这么好，为什么不用它做所有事情？”

这就涉及到 React 的架构分层了。

React 的架构主要分为三层：

1. Reconciler（协调器）： 负责找出变化（Fiber）。
2. Scheduler（调度器）： 负责安排优先级（Time Slicing）。
3. Renderer（渲染器）： 负责把 Fiber 节点变成 DOM（DOM, Native, Artboard）。

Fiber 主要存在于 Reconciler 层。

为什么不用 Fiber 做所有事？因为 Fiber 也有代价。

• 内存开销： 每一个 Fiber 节点都是一个对象，都有指针。对于巨大的树，内存消耗是巨大的。
• CPU 开销： 遍历链表比调用栈压栈要慢一点点（虽然通常可以忽略不计，因为浏览器能提供的时间切片足够弥补）。

所以，React 的哲学是：在“可中断”和“高性能”之间寻找平衡点。 我们牺牲了一点内存和一点遍历的灵活性，换取了主线程的流畅性。

---

第六部分：哲学总结——从“计算”到“响应”

好了，我们讲到了这里。让我们总结一下从 Stack 到 Fiber 的哲学转变。

Stack Reconciler 的哲学是“计算优先”：
它把渲染看作一个计算过程。只要计算没完，用户就是透明人。它像一个不知疲倦的苦力，扛着沉重的石头（组件树），一步一步往上爬，爬到顶，石头落地，任务完成。这种哲学适合小规模的、简单的场景。

Fiber Reconciler 的哲学是“响应优先”：
它把渲染看作一个交互过程。它把大石头（任务）敲碎了，变成一颗颗石子（Fiber 节点）。它时刻关注着主线程的状态，时刻准备着把控制权交还给用户。它像一个灵活的舞者，在舞台（主线程）上跳跃，累了就停，跳累了再跳，只要舞还在继续，观众就不会感到无聊。

代码视角的终极对比

Stack 时代（同步）：

function render() {
  // 这种写法，如果函数体很大，浏览器就卡死了
  if (isComplex) {
    // 做很多计算...
    // 做很多 Diff...
    // 做很多 DOM 操作...
    // 一旦卡住，整个页面冻结
  }
  requestAnimationFrame(render); // 下一帧再试
}

Fiber 时代（异步）：

function workLoop() {
  // 只做一点点
  performUnitOfWork();

  if (hasMoreWork) {
    // 告诉浏览器：“我还需要一点时间，但我现在把控制权还给你”
    requestIdleCallback(workLoop);
  } else {
    // 全部搞定，提交 DOM
    commitRoot();
  }
}

Fiber 的核心代码结构（极简版）：

function FiberReconciler(element, container) {
  // 初始化双缓冲
  let currentRoot = null;
  let workInProgressRoot = createWorkInProgress(element);

  function schedule() {
    requestIdleCallback(performUnitOfWork);
  }

  function performUnitOfWork() {
    // 1. 拿到当前节点
    const fiber = workInProgressRoot;

    // 2. 执行 Diff
    reconcile(fiber);

    // 3. 移动指针
    workInProgressRoot = fiber.next;

    // 4. 决定是继续还是暂停
    if (workInProgressRoot) {
      schedule();
    } else {
      commitRoot();
    }
  }

  return schedule;
}

---

第七部分：现代视角——React 18 的挑战

到了 React 18，Fiber 架构已经非常成熟了。但是，新的问题又出现了。

如果用户疯狂点击按钮，React 的并发模式（Concurrent Mode）能处理吗？能，但可能会造成性能浪费（白屏时间变长）。

于是，React 18 引入了 Suspense 和 Transitions。

这其实就是 Fiber 哲学的进一步延伸：更细粒度的优先级控制。以前我们区分“紧急”和“背景”，现在我们区分“普通”和“过渡”。这样，即使是一个普通的 setState，在用户没有交互的时候，也可以异步执行，而不必担心阻塞主线程。

---

结语（真正的结语）

各位同学，从 Stack 到 Fiber，这不仅仅是代码的迭代，更是前端工程化思维的一次升华。

Stack Reconciler 告诉我们：“只要我算完了，你就别想动。”
Fiber Reconciler 告诉我们：“只要你还在动，我就给你机会。”

这种转变，体现了现代前端开发的核心理念：以用户为中心。我们不再执着于“一次性算出所有结果”，而是追求“持续地、流畅地响应用户”。

Fiber 架构让 React 成为了一个真正的“响应式”框架。它不再是一个简单的 UI 库，而是一个能够感知时间、感知优先级、感知用户状态的智能系统。

这就是 Fiber 的哲学。它把复杂的递归变成了可控的链表，把同步的死锁变成了异步的流。它就像瑞士钟表里的游丝，虽然微小，却掌控着整个系统的脉搏。

希望今天的讲座能让你对 React 的内部原理有一个全新的认识。下次当你看到页面流畅滚动，或者点击按钮瞬间得到反馈时，你可以会心一笑：“哦，那是 Fiber 在帮我干活呢。”

好了，今天的课就到这里。下课！