各位同学，大家下午好！
我是你们今天的讲师，一个在 React 的坑坑洼洼里摸爬滚打多年，头发虽然稀疏但技术依然茂盛的资深工程师。
今天我们不聊那些花里胡哨的 Hooks，也不聊那些让人头秃的 TypeScript 泛型。我们要聊一个严肃的话题：防御。
在 Web 开发的世界里，没有什么是绝对安全的。你的代码写得再完美，用户的网速再快，也难免会遇到那个“万一”。当那个“万一”发生时，React 通常会像一位脾气暴躁的老太太一样，直接给你甩来一个白屏，告诉你：“哎呀，挂了。”
为了不让你的产品变成“白屏之灾”，我们需要一种机制，一种类似于“盾牌”或者“防爆盾”的东西。这就是我们今天要讲的核心——Error Boundary（错误边界）。
如果你以为 try...catch 能解决所有问题，那我要告诉你，你太天真了。try...catch 是给人类用的，React 是给机器（浏览器）用的。React 的渲染过程是同步的、声明式的，它不像你写代码那样一行一行往下跑。一旦 render 函数抛出一个异常，React 就会直接崩溃，整个应用瞬间变成一片死寂的白色。
所以，今天我们要模拟实现一个 Error Boundary，不仅要让它能工作，还要讲清楚它到底是怎么“拦截”那些致命错误的。
第一部分：React 的“玻璃心”
首先，我们要理解为什么 React 需要这种东西。
想象一下，你正在写一个复杂的 React 应用。你的组件树像一棵大树，父组件挂载了子组件，子组件又挂载了孙组件。
现在，假设在第三层（孙组件）的 render 方法里，你写了一行代码：
// 某个孙组件
render() {
const user = this.props.user;
return <div>{user.name.toUpperCase()}</div>; // 这里 user 是 undefined，会报错
}React 会怎么处理？它不会像你那样用 try...catch 把它包起来，而是会直接抛出异常。因为 React 的渲染过程是“同步”的，一旦出错，它无法回退，也无法恢复。这棵树上的所有组件都会被卸载，你的应用瞬间变成一片空白。
这就是我们所说的“白屏之灾”。
Error Boundary 的作用，就是充当这棵树上的“安检员”。它负责检查进来的子组件有没有带“炸弹”（错误），如果有，它就把炸弹拦下来，自己吞掉，然后换上一张笑脸（备用 UI）继续运行。
第二部分：核心 API 的“双人舞”
要实现一个 Error Boundary，你不能自己瞎写逻辑，React 给了我们两个关键的工具。这就像是一个保安队，两个人配合工作。
static getDerivedStateFromError(error)：这是静态方法，相当于“安检仪”。当子组件抛出错误时，React 会调用这个方法。你在这里更新状态，告诉 React：“嘿，出事了，状态变了。”componentDidCatch(error, info)：这是生命周期方法，相当于“记录员”。当错误被捕获后，这个方法会被调用。你可以在这里把错误信息发送到 Sentry、LogRocket，或者只是打印到控制台。
这里有个陷阱：getDerivedStateFromError 是同步的，而 componentDidCatch 是异步的。但更重要的是，getDerivedStateFromError 必须返回一个新的状态对象，这样 React 才知道要重新渲染。
第三部分：实战演练——编写我们的第一个 Error Boundary
好，理论讲完了，我们开始写代码。不要用那些现成的库，我们要自己造轮子，这样才能深刻理解它的原理。
1. 定义备用 UI 组件
首先，我们需要一个组件，用来展示错误信息。这个组件通常很简单，就是一个红色的警告框，加上一个“重试”按钮。
// ErrorFallback.jsx
import React from 'react';
const ErrorFallback = ({ error, resetErrorBoundary }) => {
return (
<div role="alert" style={{ padding: '20px', border: '1px solid red', color: 'red' }}>
<h2>哎呀，出错了！</h2>
<p>这不应该发生。请检查控制台。</p>
<details style={{ marginTop: '10px' }}>
<summary>错误详情</summary>
<pre>{error.toString()}</pre>
</details>
<button
onClick={resetErrorBoundary}
style={{ marginTop: '20px', padding: '10px 20px', cursor: 'pointer' }}
>
重试
</button>
</div>
);
};
export default ErrorFallback;2. 创建 Error Boundary 组件
现在，我们要把安检员写出来。注意，React 的类组件在这里是必不可少的，因为 Hooks 没法拦截错误。
// ErrorBoundary.jsx
import React, { Component } from 'react';
import ErrorFallback from './ErrorFallback';
class ErrorBoundary extends Component {
constructor(props) {
super(props);
// 初始化状态，hasError 为 false 表示一切正常
this.state = { hasError: false, error: null, errorInfo: null };
}
// 核心拦截方法 1：当子组件抛出错误时，React 会调用此方法
// 我们在这里更新状态，告诉 React 我们遇到了错误
static getDerivedStateFromError(error) {
// 更新 state，使得下一次渲染能够显示备用 UI
return { hasError: true, error };
}
// 核心拦截方法 2：当错误被捕获后，React 会调用此方法
// 我们可以在这里记录日志
componentDidCatch(error, errorInfo) {
// 记录错误日志，比如发送到服务器
console.error("ErrorBoundary 捕获到了一个错误:", error, errorInfo);
// 保存错误信息，用于展示
this.setState({
errorInfo
});
}
// 重试方法：用于在用户点击“重试”按钮时，恢复应用状态
resetErrorBoundary = () => {
this.setState({ hasError: false, error: null, errorInfo: null });
};
render() {
// 如果 hasError 为 true，说明内部出错了，渲染备用 UI
if (this.state.hasError) {
return (
<ErrorFallback
error={this.state.error}
resetErrorBoundary={this.resetErrorBoundary}
/>
);
}
// 否则，正常渲染子组件
return this.props.children;
}
}
export default ErrorBoundary;第四部分：深入解析——拦截过程是如何发生的？
这是最关键的部分。很多同学只知道怎么用，不知道为什么用。让我们来拆解一下，当错误发生时，React 内部到底发生了什么。
1. 错误的抛出
假设我们有这样的组件树：
<ErrorBoundary>
<UserProfile />
</ErrorBoundary>UserProfile 组件的 render 方法里有一个 Bug，抛出了一个异常：
// UserProfile.js
render() {
const user = this.props.user; // 假设 user 是 undefined
return <div>{user.name.toUpperCase()}</div>; // TypeError: Cannot read property 'toUpperCase' of undefined
}2. React 的检测
React 在渲染 UserProfile 时，发现它抛出了一个异常。React 会立刻停止对 UserProfile 及其所有子组件的渲染。这就像是一条生产线突然断了，机器停止运转。
3. 事件冒泡（React 术语中的“向上传播”）
React 会检查当前组件的父组件是谁。在 React 中，错误不会像 DOM 事件那样冒泡，而是会沿着组件树的“向上”层级传播。
React 会检查 ErrorBoundary 是否存在。
4. getDerivedStateFromError 的介入
如果 ErrorBoundary 存在，React 会调用它的 static getDerivedStateFromError(error) 方法。
注意： 这个方法是静态的，你不能在这里访问 this。它的作用仅仅是接收错误对象，并返回一个新的状态对象。
在这个例子中，ErrorBoundary 返回了 { hasError: true, error: error }。
5. 状态更新与重新渲染
React 收到了 ErrorBoundary 返回的新状态。它开始更新 ErrorBoundary 的状态。
由于状态更新，React 会触发 ErrorBoundary 的重新渲染。
6. componentDidCatch 的触发
在重新渲染过程中，React 捕获到了这个错误（因为错误已经被 getDerivedStateFromError 处理了，所以 componentDidCatch 不会再重复捕获）。React 会调用 ErrorBoundary 的 componentDidCatch(error, errorInfo) 方法。
这是你的最后机会，去记录日志、发送报警。
7. 渲染备用 UI
在 render 方法中，ErrorBoundary 检查 hasError 状态。因为现在是 true，所以它不再渲染子组件（this.props.children），而是渲染 ErrorFallback 组件。
最终，用户看到的是一张友好的错误页面，而不是白屏。
第五部分：Error Boundary 的“阿喀琉斯之踵”
虽然 Error Boundary 很强大，但它不是万能的。如果你对它的局限性一无所知，你可能会掉进更大的坑里。
1. 它不能捕获事件处理程序中的错误
这是最常见的误区。如果你在 onClick 或者 onChange 里面抛出错误，Error Boundary 是拦截不到的。
class UserProfile extends React.Component {
handleClick = () => {
// 这个错误 ErrorBoundary 拦截不到！
throw new Error("点击了按钮，出错了！");
};
render() {
return (
<div>
<button onClick={this.handleClick}>点击我</button>
</div>
);
}
}为什么？ 因为事件处理程序是在 React 的渲染过程之外运行的。React 只负责挂载这些事件监听器，当事件触发时，是浏览器在处理，React 根本不知道。
解决方案： 在事件处理程序里自己用 try...catch 包起来。
handleClick = () => {
try {
// 你的逻辑
} catch (error) {
console.error(error);
// 你可以在这里调用 setState 来更新 UI
}
};2. 它不能捕获异步代码中的错误
如果你在 setTimeout、fetch 或者 Promise 里抛出错误，Error Boundary 也是无能为力的。
componentDidMount() {
setTimeout(() => {
// 这个错误 ErrorBoundary 拦截不到！
throw new Error("异步出错了！");
}, 1000);
}原因： 异步代码在渲染完成后才执行，此时 React 已经完成了渲染过程，Error Boundary 已经“下班”了。
解决方案： 在异步回调里用 try...catch。
3. 它不能捕获 Error Boundary 自身抛出的错误
这是一个递归问题。如果你在 Error Boundary 的 render 方法里抛出错误，或者 Error Boundary 的子组件（也就是它自己的 children）抛出错误，Error Boundary 是无法捕获的。
render() {
// 如果你在这里抛出错误，ErrorBoundary 就会崩溃，整个应用都会挂掉！
if (this.state.hasError) {
throw new Error("ErrorBoundary 内部又出错了！");
}
return this.props.children;
}解决方案： 在应用的最外层包裹一个 Error Boundary，作为最后一道防线。
第六部分：进阶实现——如何做一个“专业级”的 Error Boundary
上面的代码虽然能用，但在生产环境中还远远不够。我们需要一个更健壮、更易用的版本。
1. 添加重试逻辑
当用户点击重试时，我们不仅要重置状态，还要重置子树。React 的子树状态比较复杂，直接重置状态可能不够。我们可以利用 key 属性来强制重新挂载子组件。
// 在 ErrorBoundary 中
resetErrorBoundary = () => {
this.setState({ hasError: false, error: null, errorInfo: null });
// 通过改变 key，强制 React 重新挂载子组件
this.setState({ key: Math.random() });
};2. 错误日志上报
在生产环境中，我们不能只在控制台打印日志。我们需要把错误信息发送到服务器。
我们可以使用 window.onerror 或者 window.addEventListener('unhandledrejection', ...) 来捕获全局错误，然后结合 Error Boundary 的 componentDidCatch，将错误信息汇总发送。
3. 自定义 Hooks 版本的 Error Boundary
类组件写起来太啰嗦了，而且容易出错。我们可以用 HOC (Higher Order Component) 或者自定义 Hooks 来封装它。
这里我们演示一个基于 Hooks 的实现思路（虽然标准的 Hooks 无法直接捕获错误，但我们可以利用 useEffect 和 useReducer 模拟）。
// useErrorHandler.js
import { useState, useEffect } from 'react';
export function useErrorHandler() {
const [error, setError] = useState(null);
useEffect(() => {
const errorHandler = (error) => {
setError(error);
console.error(error);
};
window.addEventListener('error', errorHandler);
window.addEventListener('unhandledrejection', (event) => {
event.preventDefault(); // 阻止控制台报错
errorHandler(event.reason);
});
return () => {
window.removeEventListener('error', errorHandler);
window.removeEventListener('unhandledrejection', errorHandler);
};
}, []);
const resetError = () => setError(null);
return [error, resetError];
}
// 使用示例
function UserProfile() {
const [error, resetError] = useErrorHandler();
const handleClick = () => {
try {
// 业务逻辑
} catch (err) {
setError(err);
}
};
if (error) {
return <div>Error: {error.message}</div>;
}
return <button onClick={handleClick}>点击</button>;
}第七部分：架构视角——Error Boundary 在 Fiber 树中的位置
为了更深入地理解，我们需要从 React 的底层架构——Fiber 来看。
React 的渲染过程是基于 Fiber 树的。每个 Fiber 节点代表一个组件实例。
当你渲染一个组件树时，React 会创建一个 Fiber 树。
- 正常渲染： React 递归遍历 Fiber 树，调用组件的 render 方法。如果一切顺利，屏幕更新。
- 错误发生： 当某个 Fiber 节点的 render 方法抛出异常时，React 会立即停止遍历。
- 向上查找： React 会沿着 Fiber 树的指针，向上查找最近的、实现了
componentDidCatch的父级 Fiber 节点。
这个查找过程非常快，因为 Fiber 树本身就是一棵树。一旦找到，React 就会暂停当前分支的渲染，并标记该分支为“错误状态”。
然后，React 会重新渲染这个父级组件（Error Boundary）。在新的渲染周期中，Error Boundary 的 getDerivedStateFromError 会拦截错误，更新状态，并渲染备用 UI。
这种机制保证了错误不会“越级”传播，而是被限制在最近的 Error Boundary 范围内。
第八部分：总结与最佳实践
好了，同学们，今天的讲座接近尾声。让我们回顾一下今天的重点。
- Error Boundary 是什么？ 它是一个 React 组件，用于捕获子组件树中的 JS 错误，并显示备用 UI。
- 核心方法：
getDerivedStateFromError（更新状态）和componentDidCatch（记录日志）。 - 局限性： 它不能捕获事件处理程序、异步代码和自身错误。
- 实现技巧： 使用
key属性重置子树，使用 Sentry 等工具上报日志。 - 架构原理： 错误沿着 Fiber 树向上冒泡，直到被最近的 Error Boundary 捕获。
最后，我想给大家一个忠告。
不要过度使用 Error Boundary。
Error Boundary 的开销是存在的。每次状态更新，React 都要检查是否在 Error Boundary 的范围内。如果你的应用里到处都是 Error Boundary，渲染性能会下降。
你应该在关键路径上使用 Error Boundary。比如在应用的最外层包裹一个全局的 Error Boundary，在页面切换时包裹一个路由级的 Error Boundary。不要在一个简单的列表项里也套一个 Error Boundary，那样太重了。
保护你的应用，就像保护你的钱包一样。 但也要注意，不要为了省钱，在钱包上扎满了洞。
好了，今天的课就到这里。下课！希望大家都能写出健壮、稳定、没有白屏之灾的 React 应用。如果有任何问题，欢迎在评论区留言，我们下期再见！