递归的终结：React 如何在深渊中拯救你的堆栈
各位未来的 React 守门员们，大家下午好！
今天我们不聊 Hooks 的玄学，也不谈 Context 的骚操作，我们要聊聊一个让无数前端工程师在深夜崩溃的终极难题——堆栈溢出。
想象一下，你正在写一个组件，写着写着，你觉得“递归调用”真香啊，于是你写了一个 <MyComponent />，然后在里面又 <MyComponent />，以此类推，直到你写了 5000 层。当你点击运行，浏览器弹出了那行令人心碎的红色警告：
Uncaught RangeError: Maximum call stack size exceeded.
那一刻，你的 CPU 像是一头发疯的野猪，风扇狂转，然后——死机。
React 是怎么做到的？它怎么能在处理超深组件树（比如 10,000 层）的时候，既不把你的浏览器弄死，又能把页面渲染出来？今天，我们就化身代码侦探，潜入 React 的源码深处，看看它是如何把“递归”这个猛兽驯化成“迭代”的。
第一幕：递归的诅咒与浏览器的愤怒
首先，我们得明白，为什么浏览器讨厌递归。
在计算机科学的世界里，递归就像是“传销”。函数调用函数，函数调用函数，一层套一层。每调用一次，浏览器就得在内存里给你留一张“票据”（栈帧），记录你现在的位置、局部变量、参数。
如果你递归了 1000 层，浏览器内存里就有 1000 张票据叠在一起。这就像你把 1000 本书叠在桌子上，想从最下面拿一本书，你得先挪开上面 999 本。这就叫“调用栈”。
React 早期就是这么干的。它是一个深度优先的递归遍历器。它进入根节点，处理子节点，处理孙节点，处理重孙节点……直到叶子节点，然后回溯。
在 React 16 之前，如果你有一个 10,000 层深度的组件树，React 就会变成一个巨大的、沉重的、死循环的递归函数。浏览器会立刻报警：“嘿，哥们，你的栈满了！我要炸了！”
所以，React 的第一个任务就是：别再调用函数了，改用循环！
第二幕：Fiber 架构——把“函数调用栈”变成“链表”
React 16 引入了 Fiber 架构。这听起来像是个什么高深莫测的纺织术语，其实它就是一种数据结构。
React 决定放弃使用 JavaScript 的调用栈来管理渲染过程，转而自己维护一套数据结构。这套结构的核心就是 Fiber 节点。
你可以把 Fiber 节点想象成一颗树上的“节点”，但这个树不是 DOM 树，而是一个链表。
每个 Fiber 节点都有几个关键属性，它们决定了渲染器的行为：
class FiberNode {
constructor(tag, pendingProps, key) {
this.tag = tag; // 类型：函数组件、类组件、HostComponent等
this.pendingProps = pendingProps; // 待处理的属性
this.key = key; // 唯一标识
// 核心结构：这是“堆栈保护”的关键
this.return = null; // 父节点
this.child = null; // 第一个子节点
this.sibling = null; // 下一个兄弟节点
this.alternate = null; // 前一次渲染的节点（用于双缓冲）
}
}注意这几个指针：return（父）、child（子）、sibling（兄弟）。这构成了一个双向链表结构（在 Fiber 树遍历中主要是单向的父子关系）。
为什么用链表？
因为链表不需要递归调用栈！你只需要一个指针，指到下一个节点，处理完再指回来，不需要“压栈”和“出栈”。
第三幕：从递归到迭代——那个改变世界的 while 循环
现在，React 不再递归了。它把递归函数拆分成了一个工作循环。
在源码中，最核心的渲染逻辑通常是这样的（简化版）：
function workLoopConcurrent() {
// 只要还有工作要做，就一直跑
while (workInProgress !== null) {
// 1. 执行当前节点的逻辑
performUnitOfWork(workInProgress);
// 2. 检查浏览器是否已经“累”了（时间切片）
if (shouldYield()) {
break; // 暂停！把控制权交还给浏览器
}
}
if (workInProgress === null) {
// 没活干了，渲染完成
onRootCompleted();
}
}看到这个 while 循环了吗？这就是堆栈保护的基石！React 不再是“死磕到底”，而是“打一枪换一个地方”。
但是，React 怎么知道该去处理哪个节点？它没有调用栈记录，怎么回溯？
这就涉及到了 performUnitOfWork 这个函数的内部魔法。它不仅处理当前节点，还负责管理“下一个节点”的指针。
源码级揭秘：performUnitOfWork
这是 React 源码中最复杂的逻辑之一，我们把它拆解开来看：
function performUnitOfWork(currentFiber) {
// 1. beginWork：创建子节点
// 如果当前节点还没处理过子节点，就创建它们
if (currentFiber.child === null) {
currentFiber.child = beginWork(currentFiber);
}
// 2. 如果有子节点，处理子节点
if (currentFiber.child !== null) {
workInProgress = currentFiber.child;
return;
}
// 3. 如果没有子节点，处理兄弟节点
let nextFiber = currentFiber;
while (nextFiber !== null) {
// completeWork：处理副作用（比如调用 useEffect，或者把虚拟DOM变成真实DOM）
completeWork(nextFiber);
// 找兄弟节点
if (nextFiber.sibling !== null) {
workInProgress = nextFiber.sibling;
return;
}
// 找父节点的兄弟节点（回溯！）
nextFiber = nextFiber.return;
}
// 没有任何兄弟节点，也没子节点了，工作结束
workInProgress = null;
}这段代码就是 React 的“堆栈保护引擎”。它手动实现了递归中的“回溯”逻辑。
- 深度优先：它先处理
child。 - 回溯：当
child处理完（completeWork），它会去寻找sibling。 - 再回溯：如果
sibling也没有了，它就回到return（父节点），去寻找父节点的sibling。
这完全是一个迭代过程，没有调用栈的溢出风险。
第四幕：动态切换执行上下文——时间切片
好了，React 不再爆炸了，它变成了一个 while 循环。但是，如果组件树真的有 10,000 层，这个循环跑起来是不是还是很慢？
想象一下，你在一个死循环里写了一行代码 console.log('hello')，这个循环跑 10 秒钟，你的控制台就会刷屏 10 秒钟。浏览器主线程会被阻塞，导致页面卡顿、掉帧，甚至无法滚动。
React 需要更聪明一点。它需要动态切换执行上下文。
这就是 时间切片。
React 利用浏览器的 requestIdleCallback（或者 React 自己的调度器）来检查当前浏览器是否处于“空闲”状态。
让我们回到 workLoopConcurrent：
function workLoopConcurrent() {
while (workInProgress !== null) {
performUnitOfWork(workInProgress);
// 关键点：检查时间
if (deadline === null || deadline.timeRemaining() > 0) {
continue; // 还有时间，继续跑
} else {
// 时间到了！
// React 做了一件极其聪明的事：它把自己“挂起”了
// 它把当前的状态（Fiber 节点位置）保存下来
// 然后把控制权还给浏览器，让浏览器去响应用户的点击、滚动等事件
requestIdleCallback(workLoopConcurrent);
return; // 退出循环，等待回调再次触发
}
}
}这就是“动态切换执行上下文”的本质。
- 阶段一（执行中）：React 在主线程上跑
performUnitOfWork，疯狂创建虚拟 DOM。 - 阶段二（暂停）：React 检测到时间不够了，它主动退出循环。此时，主线程空闲，用户可以点击按钮，浏览器可以渲染 UI。
- 阶段三（恢复）：当浏览器空闲下来（比如用户停止了操作，或者下一帧到来），
requestIdleCallback把控制权交还给 React。 - 阶段四（继续）：React 从上次中断的地方继续跑
performUnitOfWork。
这就像你在修一座桥，你不能一口气把桥修完，你得修一段，停下来让车过去（用户交互），等车过去了，再修一段。这样，即使桥再长，也不会堵车。
第五幕：上下文环境的传递——current vs workInProgress
在 React 的渲染过程中，始终存在两个执行上下文环境，或者说是两个“平行宇宙”：
- Current Fiber Tree（当前树）：这是浏览器里已经渲染出来的真实树。它是静止的，稳定的。
- WorkInProgress Fiber Tree（正在构建的树）：这是 React 正在脑子里构思的树。它是临时的，正在变化的。
React 如何在超深树中保持上下文环境不乱？
答案是：Fiber 节点自带“记忆”。
每个 Fiber 节点都有一个 alternate 属性，指向它在上一帧渲染时的那个节点。
// 源码逻辑
function reconcileChildren(current, workInProgress) {
let child = workInProgress.child;
let base = current ? current.child : null;
while (base || child) {
if (!child) {
// 如果子树还没建，就克隆一个
// 此时，React 会把 current 的属性复制过来
child = createWorkInProgress(child, workInProgress.pendingProps);
workInProgress.child = child;
} else if (!base) {
// 如果旧树没子节点但新树有，创建新的
// ...
} else {
// 如果都有，比对它们
// 这就是 Diff 算法登场的地方
// React 会检查 base 和 child 的属性是否变化
reconcileChildrenAndUpdateSlots(base, child);
}
// 指针下移
workInProgress = workInProgress.sibling;
base = base.sibling;
}
}在超深组件树中，React 通过这种链表遍历的方式，逐层比对 alternate 节点。它不需要把整个树存进内存的栈里，它只需要指针指来指去。
这保证了即便树有 10,000 层，React 的内存占用也只是 $O(N)$，而不是 $O(N^2)$（如果用栈的话，每层都需要存储引用）。
第六幕：挂载点——那个让循环不迷路的“路标”
在处理超深树时，最危险的情况是什么？是回溯。
如果你没有处理好 return 指针，React 的循环就会像一只没头苍蝇一样乱撞，或者直接中断。
React 源码中有一个非常关键的概念：挂载点。
当 performUnitOfWork 遇到一个没有子节点、也没有兄弟节点的节点时，它会执行 completeWork，然后向上回溯。如果回溯到了根节点，它就结束了。
但是，如果回溯到了一个中间节点怎么办？
这就涉及到 React 的 渲染策略。
在 React 18 中，为了支持并发渲染，React 把渲染分成了两个阶段：
- Render 阶段：计算差异，构建 Fiber 树。这个阶段是可中断的（基于
shouldYield）。 - Commit 阶段：把差异应用到真实 DOM 上。这个阶段是不可中断的，必须一口气完成。
在 Render 阶段，React 使用 while 循环，配合 return 指针进行全树遍历。
// 简化的 renderRoot 逻辑
function renderRoot(root, lanes) {
// 初始化 workInProgress 树
workInProgressRoot = createWorkInProgress(root.current, null);
// 开始循环
do {
try {
// 这里是核心：递归 -> 迭代的转换
workLoopConcurrent();
} catch (thrownValue) {
// 错误处理
}
} while (workInProgress !== null);
// 如果循环结束了，说明 Render 阶段完成，进入 Commit 阶段
commitRoot(root);
}这里有个细节：如果 workInProgress 没跑完（因为时间切片中断了），React 会怎么处理？
它会保存当前的 workInProgress 指针。当下一帧到来时，renderRoot 会再次被调用，或者 workLoopConcurrent 会继续执行。
关键点在于： React 在构建 workInProgress 树时，会动态地维护上下文。当你处理完一个节点，跳到它的兄弟节点，再跳到父节点的兄弟节点时，React 的“执行上下文”实际上是在树结构中“移动”。
这种移动是基于指针的，而不是基于函数调用的。因此，无论树有多深，React 都能精准地知道“我现在在哪”，“我要去哪”。
第七幕：真实案例——超深组件树的生存指南
让我们来模拟一个场景。假设你有这样一个组件：
// 这是一个递归地狱
function DeepTree({ depth = 0 }) {
if (depth > 10000) return null;
return (
<div>
<h1>Level: {depth}</h1>
<DeepTree depth={depth + 1} />
</div>
);
}
export default function App() {
return <DeepTree />;
}场景 A：React 15（递归模式）
- React 调用
App。 App调用DeepTree(0)。DeepTree(0)调用DeepTree(1)。- …
DeepTree(9999)调用DeepTree(10000)。DeepTree(10000)返回null。- 开始回溯…
- Boom! 栈溢出。
场景 B：React 18（Fiber + 迭代模式）
- React 初始化
FiberNode树结构。 workLoopConcurrent开始执行：- 处理根节点。
- 处理
DeepTree(0)。 - 创建
DeepTree(0)的child指向DeepTree(1)的 Fiber 节点。 - 检查时间：还有 16ms（一帧的时间）。
- 执行：处理
DeepTree(1)。 - 检查时间：还剩 5ms。继续处理
DeepTree(2)。 - 检查时间：还剩 0ms。中断！
- 切换上下文：React 把
workInProgress指针停在DeepTree(2)上，把控制权还给浏览器。 - 用户交互：用户在页面上滑动了一下。浏览器响应了。
- 恢复执行：几毫秒后，
requestIdleCallback回调触发。 - React 继续：处理
DeepTree(3)… - 最终，React 把这 10,000 层树遍历完，构建完 Fiber 树，然后进入 Commit 阶段，把 DOM 插入页面。
整个过程，没有一个超过 100 层的函数调用栈。React 就像一个耐心的挖掘机，一铲子一铲子地把土挖完，而不是试图一次性把整座山挖走。
第八幕：源码中的“动态切换”——useEffect 的伏笔
为什么 React 需要在渲染过程中动态切换上下文？
仅仅是为了不崩溃吗？不，是为了并发。
React 允许你在一个渲染周期内，多次更新状态。比如：
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
console.log('Effect runs');
}, [count]);
return (
<button onClick={() => setCount(count + 1)}>
Count: {count}
</button>
);
}如果你在一个渲染周期里点了 10 次按钮，React 会触发 10 次渲染。
如果 React 像以前那样，渲染完一次就锁死，那第 2 次渲染就会覆盖第 1 次渲染的结果。但如果 React 支持并发，它会在第 1 次渲染还没完全结束（比如还在处理第 5000 层组件）的时候，接收第 2 次点击，开始第 2 次渲染。
Fiber 架构如何支持这种混乱？
通过保存上下文。
每次渲染，React 都会创建一个新的 workInProgress 树。在处理第 2 次渲染时，React 会参考第 1 次渲染的 alternate 节点。
// 在 renderWithHooks 中
function renderWithHooks(current, workInProgress, Component, props) {
// 如果 current 存在（不是首次渲染），说明这是更新
// React 会把 workInProgress 和 current 的 hook 状态进行对比
// 从而决定是复用之前的 effect，还是创建新的 effect
// 这就是 React 能够在并发渲染中正确处理 useEffect 的原因
}这种机制确保了，即使渲染过程被打断、重启、多次执行，React 也能像时间旅行者一样，准确知道“我现在正在构建哪一层节点”，以及“我之前的上下文是什么”。
第九幕：总结——如何保护你的堆栈
好了，各位听众，让我们把镜头拉远。
React 处理超深组件树的堆栈保护，本质上是一场数据结构的革命。
- 放弃递归，拥抱迭代：用
while循环和链表指针代替函数调用栈。这是物理层面的保护，从根源上杜绝了溢出的可能。 - 时间切片：利用浏览器的空闲时间，把漫长的渲染过程切碎。这是主动的保护，防止浏览器卡死。
- 双缓冲与上下文保存：通过
current和workInProgress的切换，以及alternate指针，保存渲染状态。这是逻辑层面的保护，确保即使被打断，也能恢复现场。
所以，下次当你看到 Maximum call stack size exceeded 报错时，不要只怪自己写得烂。那是浏览器对递归的天然排斥。
而在 React 的世界里，Fiber 架构就是那位手持盾牌的骑士，在超深组件树的深渊中，用迭代和切片，为你撑起了一片不会崩溃的天空。
这就是 React 渲染过程中的堆栈保护。感谢大家的聆听，现在，让我们去写一些更深的组件吧！