各位好，欢迎来到“React 事故调查局”。我是你们的首席调查员，也是今天的主讲人。
今天我们不聊怎么写 useState，也不聊怎么把 useEffect 写得像诗歌一样优美。今天我们要聊的是那个让无数前端工程师半夜惊醒、看着浏览器屏幕变灰（或者变蓝屏）的终极话题——错误处理。
特别是，当你的 React 应用突然崩溃，或者抛出了一个未捕获的错误时，React 内部到底发生了什么？它是怎么像侦探一样，拿着一根看不见的“Fiber 指针”，在复杂的树状结构中，精准地找到那个能够“兜底”的边界，然后大喊一声：“Stop！这里就是我们要恢复的地方！”
准备好了吗？让我们揭开 React 内部错误处理的神秘面纱。这可不是那些教科书上干巴巴的几行字，这是一场关于指针、回溯和副作用恢复的硬核技术秀。
第一章：Fiber 树——那个复杂的“家族族谱”
首先，我们要搞清楚我们在跟什么打交道。React 的核心数据结构是 Fiber。
你可以把 Fiber 节点想象成你的简历，或者一张复杂的家族族谱。每一个 React 组件，都是一个 Fiber 节点。这个节点身上挂满了各种属性：type（你叫什么，是函数还是类？），props（你有什么装备？），state（你现在的状态是什么？），还有最重要的两个指针：return（你的爸爸是谁？）和 child（你最大的孩子是谁？）。
A (App)
/
B C
/ /
D E F G在这个树里，A 是 B 和 C 的父节点。在 React 的内部世界里，A.return 指向 null（因为它是根节点），A.child 指向 B。B.return 指回 A，B.child 指向 D。这就是 React 的“家族”关系。
但是，React 不只是树，它还是双缓冲的。这意味着它有两棵树：current 树（当前真实渲染在屏幕上的）和 workInProgress 树（正在我们脑子里构建、还没提交给屏幕的新树）。当你在点击按钮、更新状态时，React 其实是在疯狂地修改 workInProgress 树，等一切就绪了，再把 workInProgress 换成 current。这就像是在 Photoshop 里做图层，做好了再合并到底层。
第二章：事故现场——当 throw 发生时
现在，假设我们的应用正在执行一次渲染任务。我们处于 renderRoot 阶段，正在遍历 workInProgress 树。
突然，某个子组件抛出了一个错误。比如，我们有一个 PaymentComponent，它负责处理支付逻辑，但它的 useEffect 里写错了逻辑，或者某个 Math.random() 算错了导致除零错误。
function PaymentComponent() {
// 这里发生了错误！
const amount = calculateAmount();
// 如果 calculateAmount 抛出错误，React 怎么办？
return <div>支付金额: ${amount}</div>;
}在 React 的底层逻辑中，这不仅仅是一个 console.error 的事情。在渲染阶段，如果抛出了错误，React 会捕获它，并把这个错误对象挂载到当前正在渲染的 Fiber 节点上。
关键来了：React 不会崩溃整个进程，它会立刻停止向下渲染。
这时候，React 的调度器会问：“嘿，刚才那个 PaymentComponent 抛错了吧？现在怎么办？”
第三章：回溯——寻找最近的“避难所”
这是今天的重头戏：回溯。
React 内部有一个标志位，叫做 didCapture。一旦错误发生，这个标志位会被设置为 true。这就像是在事故现场拉起了一道黄色的警戒线。
React 会怎么做？它不会傻乎乎地继续去渲染 PaymentComponent 的兄弟节点 ShippingComponent。它需要向上回溯。
回溯的逻辑非常简单，简单到让你觉得“这也能算个技术点？”：
// 伪代码：React 内部的回溯循环
let nextUnitOfWork = workInProgressRoot; // 从根节点开始
let didCaptureError = false;
while (nextUnitOfWork) {
// 1. 检查当前节点是否是一个错误边界
if (isClassComponent(nextUnitOfWork) && nextUnitOfWork.stateNode?.catchError) {
// 如果是，并且它还没有处理过错误
if (!nextUnitOfWork.hasError) {
try {
// 尝试捕获错误
nextUnitOfWork.stateNode.catchError(error);
// 注意：这里实际上会调用 getDerivedStateFromError 和 componentDidCatch
// 但在渲染阶段，主要是在设置状态
nextUnitOfWork.hasError = true;
didCaptureError = true;
} catch (e) {
// 如果边界自己也挂了，那就继续往上找
nextUnitOfWork = nextUnitOfWork.return;
continue;
}
}
}
// 2. 核心回溯逻辑：向上移动指针
nextUnitOfWork = nextUnitOfWork.return;
// 3. 如果找到了根节点还没找到边界，那就真的崩了
if (!nextUnitOfWork) {
throw error; // 抛给 React 根，导致根崩溃
}
if (didCaptureError) {
// 如果已经捕获到错误，就停止向下渲染子树
break;
}
}看懂了吗？这就是所谓的“寻找最近的副作用恢复点”。
这个 nextUnitOfWork = nextUnitOfWork.return，就是那个神奇的 Fiber 指针。它沿着 return 指针一条路走到黑，直到找到那个标记为 didCapture 的边界组件。
第四章：副作用恢复点——不仅仅是“重渲染”
你可能会问：“找到边界了，然后呢？不就是重渲染一下那个边界组件，显示一个‘哎呀，出错了’的 UI 吗？”
错！大错特错！这涉及到 React 的生命周期和副作用。
当错误被捕获时，React 做了两件非常重要的事情：
- 状态更新（State Update）： 边界组件会调用
getDerivedStateFromError(error)。这会修改边界组件的state。 - 副作用重置（Effect Reset）： 这就是我们要讲的“副作用恢复点”的真正含义。
在 React 的 commit 阶段，所有的 DOM 更新（副作用）都会被执行。但是，当错误发生时，workInProgress 树是不完整的。它可能只渲染了边界组件，而错误组件下面的子树根本没有渲染。
React 必须决定：要不要把错误组件下面的那些子组件，从 DOM 中移除？
这里有一个非常精妙的逻辑，叫做 “Resume Point”（恢复点）。
什么是副作用恢复点？
副作用恢复点就是 Fiber 树中的一个特定节点，它标记了“在这个点之前，所有的副作用都已经应用；在这个点之后，如果有副作用需要应用，需要重新计算”。
当错误发生时，React 会中断渲染。它会记录当前正在处理的 Fiber 节点，以及它上面的副作用列表。
让我们看一段 React 源码级别的伪代码，来理解 commit 阶段是如何处理的：
function commitRoot(root) {
const finishedWork = root.current.alternate; // 这就是那个包含错误处理的 workInProgress 树
// 执行所有 Effect List 中的副作用
commitBeforeMutationEffects(finishedWork); // DOM 变更前的钩子
commitMutationEffects(finishedWork); // DOM 变更（包括卸载 DOM）
commitLayoutEffects(finishedWork); // DOM 变更后的钩子（如 useEffect）
// 如果发生了错误捕获
if (finishedWork.flags & DidCapture) {
// 这里的逻辑非常关键
// React 需要确保：被错误打断的子树，如果它们在 DOM 上留下了痕迹，必须被清理
// 或者，如果它们还没来得及渲染，就不能渲染
// 找到错误边界组件
let nearestBoundary = findNearestBoundary(finishedWork);
if (nearestBoundary) {
// 我们要“恢复”到这个边界组件的位置
// 也就是说，边界组件下面的所有兄弟节点和子节点，在这次提交中都不应该被渲染
// React 会通过调整 Fiber 树的结构，把这些节点暂时“藏”起来
// 或者更准确地说，React 会构建一个新的、不包含错误子树的 Fiber 树结构
// 在 commitMutationEffects 中，React 会遍历副作用列表
// 如果发现一个节点的 return 指向了错误边界，并且这个节点已经被标记为“需要卸载”或“需要挂载”
// React 会跳过这些节点的 commitWork，因为它们的内容是无效的（因为它们依赖于那个报错的组件）
// 简单来说：副作用恢复点就是告诉 React：
// "嘿，从这儿开始，别管了，因为上面的爹挂了，下面的小孩全是假的。"
}
}
root.current = finishedWork;
flushSyncCallbacks();
}第五章：深度解析——Fiber 标志位与 Effect List
为了真正理解“恢复点”，我们需要谈谈 Effect List。
React 在渲染阶段（render），会构建一个链表，记录所有带有副作用的节点。比如，一个组件里用了 useEffect，它就会被加入这个链表。
// 渲染阶段：构建 Effect List
function markEffectTags(workInProgress) {
// 如果当前节点有子节点，先处理子节点
if (workInProgress.child) {
workInProgress.child.return = workInProgress;
markEffectTags(workInProgress.child);
}
// 处理当前节点的副作用
if ((workInProgress.flags & HasEffect) !== NoFlags) {
// 把自己加到链表里
addEffectTagToList(workInProgress);
}
}现在，假设在构建 Effect List 的过程中，ComponentA 抛出了错误。
React 会停止构建。
此时，ComponentA 的 return 指向 ComponentB。
React 会遍历 ComponentA 的 return 指针，找到 ComponentB。
关键点来了：
React 会检查 ComponentB 是否是一个错误边界。
如果是，React 会修改 ComponentB 的状态，然后跳过构建 ComponentA 及其兄弟节点（ComponentC, ComponentD 等）的 Effect List。
为什么？因为 ComponentA 挂了，ComponentC 和 ComponentD 虽然还没渲染，但它们在逻辑上属于 ComponentA 的子树。如果 ComponentA 的状态是错的，或者 ComponentA 的逻辑被中断了，那么 ComponentC 和 ComponentD 的内容就是不确定的。
副作用恢复点的真正含义：
副作用恢复点就是那个 ComponentB。
在 commit 阶段，React 执行副作用时，它会遍历 Effect List。如果它发现一个节点的 return 指向了一个已经标记为 didCapture 的节点，React 就会停止执行这个节点的副作用。
这就像是：你在装修房子（渲染），刷墙（DOM 更新）。突然，你刷漆的刷子掉地上了（报错）。你捡起刷子（回溯），发现这是隔壁老王家的刷子（错误边界）。
你会怎么做？你会把老王刷了一半的墙（副作用）全部铲掉，或者干脆不管那部分，只负责把老王家的房间（边界组件本身）重新刷一下。
第六章：代码实战——模拟 Fiber 回溯
让我们来写一段稍微带点“黑客味”的代码，模拟一下 React 内部是如何通过 Fiber 指针回溯并找到恢复点的。
假设我们有一个组件树：
App -> Header -> Content -> ErroringComponent
// 定义 Fiber 节点结构
class FiberNode {
constructor(type, props, stateNode) {
this.type = type; // 组件类型
this.stateNode = stateNode; // DOM 节点或组件实例
this.return = null; // 父节点指针
this.child = null; // 第一个子节点
this.sibling = null; // 下一个兄弟节点
this.flags = 0; // 各种状态标志
this.state = {}; // 组件状态
this.hasError = false; // 是否已捕获错误
this.isClassComponent = false;
}
}
// 模拟 React 的错误处理核心逻辑
function handleFiberError(error, workInProgressRoot) {
console.log(`[事故] 在 ${workInProgressRoot.type} 树中检测到错误: ${error.message}`);
// 初始化回溯指针
let currentFiber = workInProgressRoot;
let foundBoundary = null;
// 开始回溯：沿着 return 指针向上爬
while (currentFiber) {
console.log(`[调查] 正在检查节点: ${currentFiber.type} (hasError: ${currentFiber.hasError})`);
// 检查当前节点是否是错误边界
// 在真实 React 中，通过判断 stateNode 是否有 componentDidCatch 等方法
if (currentFiber.isClassComponent && currentFiber.stateNode && currentFiber.stateNode.catchError) {
console.log(`[发现] 找到错误边界: ${currentFiber.type}`);
if (!currentFiber.hasError) {
// 调用边界组件的生命周期
// getDerivedStateFromError
currentFiber.stateNode.getDerivedStateFromError(error);
// componentDidCatch (在 commit 阶段调用，这里只是模拟状态改变)
console.log(`[恢复] ${currentFiber.type} 已捕获错误，状态已更新`);
currentFiber.hasError = true;
foundBoundary = currentFiber;
break; // 找到最近的边界，停止回溯
}
}
// 向上移动
currentFiber = currentFiber.return;
// 如果到了根节点还没找到边界，那就要崩了
if (!currentFiber) {
console.log("[致命] 未找到错误边界，应用崩溃！");
throw error; // 重新抛出错误，导致 React 根崩溃
}
}
return foundBoundary;
}
// 构建测试树
const App = new FiberNode('App', {}, null);
App.isClassComponent = true; // 假设 App 也是个类组件，或者只是根节点
const Header = new FiberNode('Header', {}, null);
const Content = new FiberNode('Content', {}, null);
const ErroringComponent = new FiberNode('ErroringComponent', {}, null);
// 连接指针
App.child = Header;
Header.return = App;
Header.sibling = Content; // 假设 Content 是 Header 的兄弟，或者 App 的子
// 为了简单，我们假设 Header 有个 child Content
Header.child = Content;
Content.return = Header;
Content.child = ErroringComponent;
ErroringComponent.return = Content;
// 模拟运行
const myError = new Error("Payment failed: No money left!");
handleFiberError(myError, App);在这个模拟中，你可以清晰地看到：
- 错误在
ErroringComponent抛出。 handleFiberError从App开始，沿着return指针向上遍历。- 它检查了
Content，发现它不是边界。 - 它检查了
Header，发现它也不是边界。 - 它检查了
App（根），发现它也不是边界。 - 结果： 抛出致命错误，应用崩溃。
如果我们把 Header 改成一个错误边界呢？
// 给 Header 加上错误处理能力
Header.isClassComponent = true;
Header.stateNode = {
getDerivedStateFromError: (error) => {
console.log(`[Boundary] ${Header.type} 收到错误: ${error.message}`);
// 更新状态，比如显示错误 UI
Header.state = { hasError: true };
}
};
// 再次运行
handleFiberError(myError, App);
// 输出：
// [事故] 在 App 树中检测到错误: Payment failed: No money left!
// [调查] 正在检查节点: App
// [调查] 正在检查节点: Header
// [发现] 找到错误边界: Header
// [恢复] Header 已捕获错误，状态已更新第七章：为什么 useEffect 抓不到错误？
既然我们已经讲了这么多关于回溯和副作用恢复的知识，那就必须解决一个经典的面试题：为什么 useEffect 里抛出的错误，错误边界（Error Boundary）抓不到？
这听起来很反直觉，对吧？useEffect 不也是副作用吗？
答案就在于 “副作用恢复点”的时机。
- 渲染阶段（Render Phase）： 这里是 Fiber 指针回溯的地方。如果错误在这里抛出，React 会捕获它，并沿着
return指针回溯寻找边界。这是“捕获”阶段。 - 提交阶段（Commit Phase）： 这里是执行副作用的地方，包括
useEffect。
当 useEffect 运行时，React 已经完成了错误捕获。它已经决定：
- 是否有错误边界捕获了错误。
- 如果有，错误边界组件已经被渲染了新的 JSX。
- 如果没有，React 根节点已经崩溃了，整个应用都停了。
此时，如果你在 useEffect 里抛出错误，React 已经不在“渲染阶段”了。它是在“提交阶段”抛出的错误。这个阶段的错误无法被“渲染阶段”的回溯机制捕获，因为回溯机制已经结束了。它会直接导致 React 的执行线程崩溃，或者被 React 的顶层错误监听器捕获（这通常是致命的）。
所以，useEffect 里的错误是“死刑”，而渲染阶段抛出的错误是“流放”（去错误边界里蹲着）。
第八章：深度挖掘——Fiber 指针与 DOM 节点的同步
回到我们的主题：通过 Fiber 指针寻找最近的副作用恢复点。
这不仅仅是逻辑上的回溯，更是物理上的同步。当错误边界捕获错误并渲染新树时，这个新树的结构可能与旧树不同。旧的 ErroringComponent 节点被移除了，取而代之的是 BoundaryComponent。
React 如何知道旧的 ErroringComponent 对应的 DOM 节点在哪里，并把它从屏幕上删掉？
这里涉及到 Fiber 节点的 alternate 属性（双缓冲机制）。
current树： 指向旧的 DOM 结构。workInProgress树： 指向新的（包含错误处理的）结构。
在 commit 阶段，React 会对比这两棵树。
- 它会遍历
workInProgress树。 - 对于每个节点，它检查
current树中是否有对应的节点。 - 如果没有（比如错误组件被移除了），React 就会卸载 DOM。
- 如果有（比如边界组件重新渲染了），React 就会复用 DOM。
副作用恢复点在这里起到了导航作用。
当错误发生时，workInProgress 树被破坏了。React 的 commit 阶段逻辑会利用 workInProgress.return 指针，快速定位到错误边界。然后，React 会执行一个特殊的逻辑：“剪断”。
它会遍历错误边界之下所有的子树，将它们从 workInProgress 树中暂时切断，或者标记为“无效”。
这就像是在修车。引擎（错误组件）坏了。修车工（错误边界）介入了。他不需要继续修变速箱（下面的子组件），也不需要管轮胎（兄弟组件）。他只需要把坏掉的引擎拆下来，换一个新的，然后重新组装引擎盖（边界组件本身）。至于车身其他部分，保持原样即可。
第九章：性能的代价——回溯的开销
最后，我们要聊聊性能。
这种回溯机制虽然保证了应用的健壮性，但它是有代价的。每次状态更新，如果一切顺利，React 会从根节点开始，通过 child 和 sibling 指针线性遍历整棵树（对于简单的树）。
如果发生错误，React 还要额外执行一次回溯。虽然回溯通常很快（只是指针移动），但如果你的树很深，或者错误边界嵌套得很深，这也会带来一些额外的开销。
此外，因为错误边界会触发重新渲染，这可能导致父组件也跟着重新渲染，形成连锁反应。这就是为什么 React 官方不建议滥用错误边界，或者把它作为主要的错误处理手段（你应该在代码逻辑里处理错误，而不是依赖边界）。
第十章：总结——当指针指向未来
好了，我们讲了这么多。
React 的错误处理，本质上是一场在数据结构上的精密舞蹈。
- Fiber 指针 是你的导航仪。
- 回溯 是你的逃生路线。
- 副作用恢复点 是你的安全屋。
当错误发生时，React 并没有选择“死机”。它选择了一条更聪明的路：暂停当前的执行流，利用 return 指针向上攀登，寻找那个能兜底的边界组件，然后在那里重建世界。
这就是 React 的韧性。它允许你的应用在崩溃的边缘跳舞，只要你给它一个正确的边界。
希望今天的讲座能让你对 React 的内部机制有更深的理解。下次当你看到屏幕上出现红色的错误信息时，别再只是叹气了。闭上眼睛，想象一下那个 Fiber 节点正在沿着 return 指针艰难地向上爬，寻找它的救赎。
谢谢大家！现在，去修复你的代码吧，别让那些指针失望！