嘿，各位码农！今天咱们不聊那些虚头巴脑的架构设计模式，咱们来聊聊 React 16 之前那个让无数前端工程师头秃的“同步地狱”，以及 React 团队是如何通过一种叫做“Fiber”的魔法，把这个地狱变成“切片披萨”的。
准备好了吗？咱们把那个名为“React Fiber”的神秘盒子打开，看看里面的齿轮是怎么转的。
第一章：那个被递归“吃掉”的主线程
首先，咱们得回到 2017 年左右。那时候的 React 还是个“猛男”。为什么这么说？因为它太“同步”了。
想象一下，你的主线程（浏览器用来跑 JavaScript 的那个单线程环境）就像是一个正在处理订单的超级咖啡师。React 16 之前的渲染逻辑，就像是这个咖啡师接到了一个订单：“老板，我要一杯全糖、加奶、双份浓缩、还要在杯子上画个爱心的超大杯拿铁！”
如果按照以前的逻辑，这个咖啡师（主线程）必须一口气把这杯拿铁做完，不能停，不能喘气，甚至不能上厕所。他得先把配方写下来，把奶泡打匀，把浓缩倒进去，最后画爱心。如果这杯拿铁太复杂，或者奶泡打得太久，后面的顾客（比如用户点击了“提交”按钮）就只能干等着。这就叫“阻塞”。
在 React 里，这种阻塞是怎么发生的呢？就是递归。
以前的 React 渲染，本质上是把整棵虚拟 DOM 树（那棵长得像迷宫一样的树）递归地遍历了一遍。它是一个“吃豆人”游戏，它在树里一路吃，吃完了这一层，再吃下一层，直到把所有的节点都访问一遍，计算出差异，然后更新 DOM。
问题来了： 递归是“一气呵成”的。如果这棵树有几千个节点，JavaScript 的调用栈（Stack）就会像滚雪球一样越来越大。一旦栈溢出，或者时间超过了浏览器分配给脚本的 16ms（即一帧的时间），用户的界面就会卡死，滚动条会卡顿，点击事件会无响应。这就是所谓的“主线程阻塞”。
当时的 React 就像一个不会休息的马拉松选手，让他一口气跑完 42 公里，跑着跑着他就累瘫了，甚至倒地不起。
第二章：Fiber 的诞生——给递归“打补丁”
React 团队意识到，光靠优化虚拟 DOM 的 Diff 算法是不够的，因为底层的执行机制（递归调用栈）本身就是个大问题。于是，他们决定重构 React 的底层架构，引入了一个新概念：Fiber。
Fiber 听起来像是什么高科技材料，其实它就是个“工作单元”（Work Unit）。
为什么叫 Fiber？因为它把那棵巨大的、不可中断的树，拆成了一根一根的“纤维”。原本的 React 是“整体作战”，现在的 Fiber 是“游击队作战”。
2.1 从“树”到“链表”
以前 React 是递归地遍历树结构：
// 伪代码：旧版 React 的递归思维
function renderTree(node) {
if (!node) return;
// 处理当前节点
reconcile(node);
// 递归处理子节点
renderTree(node.child);
// 递归处理兄弟节点
renderTree(node.sibling);
}这种写法最爽，但最致命。一旦卡在 renderTree 的中间，你就出不来。
现在的 Fiber，把这种递归改成了链表遍历。每一个节点都是一个对象，这个对象里不再只是存数据，还存了“路标”。
每个 Fiber 节点有三个关键属性：
child: 第一个子节点。sibling: 下一个兄弟节点。return: 父节点。
这就好比把一棵树倒过来，变成了一条长龙。你只需要拿着一个指针，从龙头走到龙尾，甚至可以随时停下来。
2.2 Fiber 节点的“身份证”
为了能在遍历过程中保存状态，Fiber 节点变得非常丰满。它不仅仅是个简单的对象，它是个“微型状态机”。
// FiberNode 的简化结构
class FiberNode {
constructor(tag, type, props) {
// 标签：告诉我们这个节点是个什么组件
this.tag = tag;
// 类型：函数组件、类组件、原生 DOM (div, span)
this.type = type;
// 属性：props
this.props = props;
// 指针：链表结构
this.child = null; // 第一个孩子
this.sibling = null; // 下一个兄弟
this.return = null; // 父节点
// 核心中的核心：双缓冲用到的 alternate
this.alternate = null;
// 状态
this.pendingProps = props;
this.memoizedProps = props;
this.memoizedState = null;
// 副作用：标记这个节点有没有需要更新的地方
this.effectTag = null;
}
}你看，这个 effectTag 是个关键。它就像是给每个节点打了个标签：Placement（新增）、Update（修改）、Deletion（删除）。React 在遍历树的时候，只把这些标签打上去，不做具体的 DOM 操作。具体的 DOM 操作，要等到下一阶段再说。
第三章：双缓冲——导演剪辑版与公映版的博弈
好了，咱们现在有了“游击队”（Fiber 节点链表），也有了“标签”（effectTag）。但是，React 怎么知道怎么更新 DOM 呢？它总不能一边算一边改吧？
这就引出了 React Fiber 架构最精妙的地方：双缓冲技术。
3.1 什么是双缓冲？
在计算机图形学里，双缓冲是为了防止画面闪烁。但在 React 里，双缓冲的意思是：同时存在两棵树，一棵是现在的，一棵是正在做的。
- Current Tree（当前树）： 就是现在屏幕上显示的那棵树。它是“公映版”，已经经过观众（用户）检验过了。
- WorkInProgress Tree（工作树）： 这是正在后台构建的树，它是“导演剪辑版”或者“草稿”。React 正在尝试修改它，看看能不能变成更好的版本。
为什么要这样做？
因为 React 需要计算差异（Diff）。如果你直接修改 Current Tree，万一计算错了怎么办？或者计算到一半被中断了怎么办？
双缓冲的切换原理：
- 初始化： 当你第一次渲染组件时，Current Tree 和 WorkInProgress Tree 可能指向同一个对象（或者 WorkInProgress 是一个新的克隆）。
- 构建 WorkInProgress Tree： React 开始遍历 WorkInProgress Tree。它读取 Current Tree 的状态，计算出新的状态，把差异打上
effectTag，然后构建 WorkInProgress Tree 的新结构。 - 提交更新： 当 WorkInProgress Tree 构建完成，并且所有逻辑都跑通了，React 就会做一个“乾坤大挪移”的操作：交换指针。
currentNode = workInProgressNodeworkInProgressNode = currentNode.alternate
- 垃圾回收： 此时，旧的 Current Tree 就变成了“孤儿”。JavaScript 的垃圾回收器（GC）会把它回收掉。
3.2 代码演示双缓冲切换
为了让你更直观地理解，咱们写一段伪代码来模拟这个过程。
假设我们有一个简单的场景：
- 初始状态：A -> B -> C
- 更新状态：A -> B -> D （C 被删掉，D 被加进来）
// 1. 定义 Fiber 节点
function createFiber(type) {
return {
type,
child: null,
sibling: null,
return: null,
alternate: null, // 双缓冲的关键
effectTag: null, // 副作用标记
};
}
// 2. 初始化两棵树
// 初始渲染
let currentTree = null; // 初始为空
let workInProgressTree = null;
function mountRoot() {
// 创建根节点
let rootFiber = createFiber('HostRoot');
let childFiber = createFiber('HostComponent', 'div');
// 建立父子关系
rootFiber.child = childFiber;
childFiber.return = rootFiber;
// 初始阶段，双缓冲还没开始，current 还没挂载
// 实际上，这里 workInProgress 就是正在构建的
workInProgressTree = rootFiber;
// 模拟构建子节点...
let siblingFiber = createFiber('HostComponent', 'span');
childFiber.sibling = siblingFiber;
siblingFiber.return = rootFiber;
console.log("初始树构建完成:", rootFiber);
}
// 3. 模拟状态更新
function updateTree() {
// 假设我们更新了逻辑，要把 'span' 变成 'p'
// 并且 'p' 下面挂载了 'div'，而 'span' 要被卸载
let current = workInProgressTree; // 此时 current 指向 workInProgress
// 生成新的 workInProgress 节点
let newRoot = createFiber('HostRoot');
let newChild = createFiber('HostComponent', 'p'); // 类型变了
// 建立关系
newRoot.child = newChild;
newChild.return = newRoot;
// 假设 p 下面有个 div
let newGrandChild = createFiber('HostComponent', 'div');
newChild.child = newGrandChild;
newGrandChild.return = newChild;
// --- 核心切换时刻 ---
// 把新构建的树作为新的 workInProgress
workInProgressTree = newRoot;
// 关键一步：建立双缓冲指针
// 新树的 alternate 指向旧树
newRoot.alternate = current;
// 旧树的 alternate 指向新树
current.alternate = newRoot;
// 更新 current 指针
// 此时，current 指向了新构建的树（虽然还没提交 DOM，但在逻辑上是新的了）
current = newRoot;
console.log("双缓冲切换完成！");
console.log("旧树:", current.alternate); // 这就是即将被回收的垃圾
console.log("新树:", current);
}在这个例子中，current.alternate 指向了 workInProgress，而 workInProgress.alternate 指向了 current。这就形成了一个完美的闭环。
为什么要这样绕？
因为 React 需要对比。当它构建新树（WorkInProgress）时，它需要参考旧树（Current）的数据（比如 memoizedProps）来做 Diff。有了 alternate 指针，React 就可以在不破坏当前树的情况下，安全地读取旧树的数据。
第四章：时间切片与 requestIdleCallback
有了 Fiber，React 终于可以“喘口气”了。但是，怎么控制“喘气”的节奏呢？这就涉及到了调度。
4.1 时间切片
React 不再试图一次性遍历完整棵树，而是把任务切成无数个微小的切片。
比如，浏览器告诉 React：“嘿，我有 3ms 的空闲时间，你随便用。”
React 就会接过来，说：“好嘞！”然后它只处理 3ms 的任务。处理完这 3ms，React 会说：“时间到了，老板来了，我得暂停。”
然后它把当前的状态保存好（保存在 Fiber 节点的 alternate 里），把控制权交还给浏览器。浏览器去渲染刚才那 3ms 的结果，处理用户的点击、滚动。
过了一会儿，浏览器又有空闲了，又喊：“React，还有空吗？”
React 又说：“有！继续干活！”
这就是时间切片。
4.2 requestIdleCallback
React 使用了一个叫做 requestIdleCallback 的 API（在 React 18 中演变成了 scheduler 包）。这个 API 允许脚本在浏览器主线程空闲时执行低优先级的任务。
但是，React 还得处理高优先级的任务（比如用户点击了按钮，必须马上响应）。所以 React 内部维护了一个任务队列，里面有不同的优先级。
代码逻辑大概是这样的（简化版）：
// 伪代码：调度器的工作
let deadline = {
timeRemaining: () => 5000 - Date.now(), // 剩余时间
didTimeout: false
};
function workLoop(deadline) {
// 只要还有时间，而且还有任务没做完
while (deadline.timeRemaining() > 0 && tasks.length > 0) {
// 取出最紧急的任务
const task = tasks.shift();
// 执行任务（这里就是 Fiber 的渲染过程）
performUnitOfWork(task.fiber);
}
if (tasks.length > 0) {
// 还有任务，继续请求空闲时间
requestIdleCallback(workLoop);
} else {
// 没任务了，说明渲染完成，准备提交
commitRoot();
}
}
// 启动调度
requestIdleCallback(workLoop);你看到了吗？React 就像一个在后台默默工作的程序员。主线程在处理 UI 交互，React 在后台偷偷地把任务切完。当所有任务都切完的那一刻，就是“提交阶段”的开始。
第五章：提交阶段——DOM 的最后狂欢
现在，WorkInProgress Tree 已经构建完毕，所有的 effectTag（增删改）都已经打好了。
接下来的阶段叫 Commit Phase（提交阶段）。这个阶段是同步的。
为什么是同步的？
因为这是最后一步了。你不能再让用户等了。你必须把计算好的结果，实实在在地反映在 DOM 上。
5.1 提交流程
- 遍历 WorkInProgress Tree： React 从根节点开始遍历。
- 处理 Effect Tags：
- 如果是
Placement（新增）：创建 DOM 节点，插入到父节点里。 - 如果是
Update（修改）：更新 DOM 节点的属性（比如className,style）。 - 如果是
Deletion（删除）：从 DOM 中移除节点。
- 如果是
- 更新 Fiber 链接： 在插入或删除 DOM 的同时，React 会更新 Fiber 节点的
child,sibling,return指针，确保它们指向正确的位置。 - 滚动处理： React 会处理滚动位置，防止页面跳动。
- 触发 Effect： 执行
useEffect回调。
代码示例：提交阶段的简化
function commitRoot() {
let current = workInProgressTree;
let next = current.alternate;
// 1. 遍历并执行副作用
commitWork(next.child);
// 2. 切换指针，完成双缓冲
current = next;
// 此时，current 指向的就是 WorkInProgress Tree（也就是新树）
// 它已经准备好接管屏幕了
}
function commitWork(fiber) {
if (!fiber) return;
let domParent = fiber.return;
// 循环找到真正的 DOM 父节点
while (domParent.tag !== 'HostComponent') {
domParent = domParent.return;
}
// 根据 effectTag 决定操作
if (fiber.effectTag === 'Placement') {
// 创建 DOM
const newDom = fiber.stateNode; // 假设 stateNode 存着真实的 DOM 引用
domParent.stateNode.appendChild(newDom);
} else if (fiber.effectTag === 'Update') {
// 更新 DOM
const domNode = fiber.stateNode;
const oldProps = fiber.alternate.memoizedProps;
const newProps = fiber.memoizedProps;
if (newProps !== oldProps) {
// 比较并更新属性...
updateDOMProperties(domNode, oldProps, newProps);
}
} else if (fiber.effectTag === 'Deletion') {
// 删除 DOM
domParent.stateNode.removeChild(fiber.stateNode);
}
// 递归处理子节点
commitWork(fiber.child);
// 递归处理兄弟节点
commitWork(fiber.sibling);
}在这个阶段，React 必须同步执行完所有操作。因为它必须保证 DOM 的状态是原子性的。你不能把一个组件的 DOM 删了一半，然后突然去渲染另一个组件的 DOM。
第六章：深入理解 Fiber 节点的生命周期
咱们再来聊聊 Fiber 节点本身，特别是它那神奇的 alternate 属性。
6.1 双缓冲的魔法时刻
还记得那个 commitRoot 吗？在提交阶段，React 完成了 DOM 更新。此时，它要做最后的一步操作：
// React 源码中的关键逻辑
function commitRoot() {
// ... 执行 DOM 更新 ...
// 1. 更新 workInProgress 树的 alternate 指针，使其指向 current
workInProgress.alternate = current;
// 2. 更新 current 树的 alternate 指针，使其指向 workInProgress
current.alternate = workInProgress;
// 3. 把 workInProgress 赋值给 current
// 此时，current 指向了新构建的树
current = workInProgress;
// 4. workInProgress 现在可以变成下一轮更新的“旧树”了
// 所以我们需要创建一个新的 workInProgress 树
workInProgress = createWorkInProgress(current, nextPayload);
// 5. 立即进入下一轮调度
requestIdleCallback(workLoop);
}你看，current 和 workInProgress 就像是在玩“石头剪刀布”。上一轮的 workInProgress 变成了这一轮的 current，而这一轮的 workInProgress 是新创建的。
这个循环往复，就是 React 生命周期的本质。
6.2 Fiber 的“记忆”
Fiber 节点不仅仅是 DOM 的镜像，它还存了“记忆”。每个节点都有 memoizedProps 和 memoizedState。
这是为了做什么呢？为了做增量更新。
当 React 下一次渲染时，它不需要重新创建所有的 Fiber 节点。它会复用旧的节点（通过 alternate 指针找到），然后只更新那些变了的部分。
比如，你有一个列表，你只修改了第一个列表项的内容。
React 在构建新的 WorkInProgress Tree 时：
- 它找到第一个列表项的 Fiber 节点。
- 它发现
fiber.alternate存在。 - 它读取
fiber.alternate.memoizedProps，发现是旧的。 - 它比较新 props 和旧 props，发现只有一个是变的。
- 它打上
Update标签。 - 它跳过后面的列表项（假设后面的没变），直接处理兄弟节点。
这大大提高了性能。如果每一帧都重新创建整棵树，那还叫什么 Fiber？那叫“全量重建”，性能会差到令人发指。
第七章：Fiber 的“副作用”世界
咱们前面提到了 effectTag。这是 Fiber 架构中非常有趣的一部分。
在 React 的渲染阶段，Fiber 节点只负责“标记”。它们不知道自己到底要删还是改，它们只知道“我可能要干点啥”。
所有的 DOM 操作都被归类到了 effectTag 中。这些标签在提交阶段才会被真正执行。
常见的 effectTag 有：
NoEffect: 没什么变化。Placement: 新增节点。Update: 更新属性。Deletion: 删除节点。Placeholder: 暂时占位（用于 Suspense）。Hydrating: 水合（SSR 相关）。
这种分离（渲染阶段只标记，提交阶段才操作）保证了渲染阶段可以随时被打断。因为标记操作非常轻量级，不需要操作 DOM。一旦进入提交阶段，DOM 操作是同步的，但此时已经没有复杂的计算了，只是简单的增删改查。
第八章：总结——Fiber 是如何改变一切的
让我们回顾一下 React Fiber 的旅程。
- 痛点： 旧版 React 的递归渲染阻塞了主线程，导致 UI 卡顿。
- 方案： 引入 Fiber 架构，将递归树改为链表遍历，支持时间切片。
- 核心机制： 双缓冲。利用
alternate指针，在构建新树的同时保留旧树的数据，确保 Diff 算法的正确性和可中断性。 - 执行流程： 渲染阶段（可中断，异步） -> 提交阶段（同步，DOM 更新）。
Fiber 的出现，让 React 从一个“笨重的巨兽”变成了一个“灵活的刺客”。它可以在不卡死主线程的情况下，处理极其复杂的 UI 更新。
它就像是一个精细的瑞士钟表。虽然内部齿轮咬合极其复杂，但外表看起来却精准、流畅、毫秒不差。
代码示例：一个完整的 Fiber 渲染周期模拟
为了彻底把这件事讲透，咱们来写一个更完整的、包含调度和提交的模拟代码。
// --- 1. 定义 Fiber 节点 ---
class FiberNode {
constructor(tag, type, props) {
this.tag = tag;
this.type = type;
this.props = props;
this.stateNode = null; // 实际的 DOM 节点
// 链表结构
this.return = null;
this.child = null;
this.sibling = null;
// 双缓冲
this.alternate = null;
// 状态
this.memoizedProps = null;
this.memoizedState = null;
// 副作用
this.effectTag = NoEffect;
}
}
const NoEffect = 0;
const Placement = 1;
const Update = 2;
// --- 2. 模拟渲染阶段 ---
let nextUnitOfWork = null;
function render(element) {
// 创建根节点
let rootFiber = new FiberNode(0, 'Root', null);
let hostFiber = new FiberNode(1, 'div', { className: 'container' });
// 建立关系
rootFiber.child = hostFiber;
hostFiber.return = rootFiber;
// 设置 memoizedProps
hostFiber.memoizedProps = { className: 'container' };
// 设置 stateNode (模拟 DOM 创建)
hostFiber.stateNode = document.createElement('div');
hostFiber.stateNode.className = hostFiber.memoizedProps.className;
nextUnitOfWork = rootFiber;
// 开始调度
requestIdleCallback(workLoop);
}
function workLoop(deadline) {
// 只要还有时间，就继续工作
while (nextUnitOfWork && deadline.timeRemaining() > 0) {
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
}
if (nextUnitOfWork) {
requestIdleCallback(workLoop);
} else {
// 没有工作单元了，说明渲染完成，准备提交
commitRoot();
}
}
function performUnitOfWork(fiber) {
// 如果有子节点，先处理子节点
if (fiber.child) {
return fiber.child;
}
// 如果有兄弟节点，处理兄弟节点
if (fiber.sibling) {
return fiber.sibling;
}
// 没有子节点，也没有兄弟节点，返回父节点，继续处理父节点的兄弟
return fiber.return;
}
// --- 3. 模拟提交阶段 ---
function commitRoot() {
let currentFiber = workInProgressTree.child;
while (currentFiber) {
// 处理 Placement
if (currentFiber.effectTag === Placement) {
commitPlacement(currentFiber);
}
// 处理 Update
if (currentFiber.effectTag === Update) {
commitUpdate(currentFiber);
}
// 递归处理子节点
currentFiber = currentFiber.child;
}
// 双缓冲切换完成
current = workInProgressTree;
workInProgressTree = createWorkInProgress(current, nextPayload);
}
function commitPlacement(fiber) {
// 找到父节点
let parentFiber = fiber.return;
while (parentFiber.tag !== 1) {
parentFiber = parentFiber.return;
}
// 插入 DOM
parentFiber.stateNode.appendChild(fiber.stateNode);
}
function commitUpdate(fiber) {
// 更新 DOM 属性
const dom = fiber.stateNode;
const oldProps = fiber.alternate.memoizedProps;
const newProps = fiber.memoizedProps;
// 简单的属性更新逻辑
for (let key in newProps) {
if (key !== 'children' && oldProps[key] !== newProps[key]) {
dom[key] = newProps[key];
}
}
}
// --- 4. 模拟调度器 ---
let current = null;
let workInProgressTree = null;
let nextPayload = null;
// 启动
render(<div className="root" />);看完这段代码，你应该能感受到 Fiber 的脉搏了。它不是魔法，它是工程学。它是通过牺牲一点代码的复杂性，换取了巨大的运行性能和用户体验的提升。
结语：从 Fiber 到并发模式
最后，咱们得提一句。Fiber 只是第一步。React 18 引入了“并发模式”，这是对 Fiber 的进一步升华。
并发模式意味着 React 可以更聪明地管理任务的优先级。比如，当一个高优先级的任务（用户输入）进来时，React 可以暂停低优先级的任务（比如正在加载的大图），先去处理用户的输入，然后再回来继续处理那张大图。
Fiber 架构就是这一切的基础。没有 Fiber 的链表结构，没有双缓冲的指针魔法，没有时间切片的调度器，并发模式根本无从谈起。
所以，下次当你看到 React 那么丝滑的动画和响应速度时，别忘了那个在后台默默工作的 Fiber 节点。它就像是一个不知疲倦的园丁，在代码的丛林里，修剪着每一棵树的枝叶，确保它们永远生机勃勃，永不卡顿。
好了，今天的讲座就到这里。如果觉得有点晕，没关系，Fiber 本身就是一个反直觉的东西。多看源码，多画图，你终会征服它。咱们下次见！