React 全栈错误边界捕获与堆栈还原：一场与“炸服”的猫鼠游戏

各位同学，大家好！

欢迎来到今天的讲座，主题是《React 全栈错误边界捕获与堆栈还原》。我是你们今天的讲师，一个在代码世界里当了多年“消防员”的老兵。

在开始之前，我想问大家一个问题：你们有没有过这种体验？你在本地敲代码，顺风顺水，喝着咖啡，敲下 npm start，然后——啪！屏幕上一片空白，控制台里跳出一行红色的 Uncaught Error: Something went wrong。你的第一反应是什么？

99% 的人会掏出手机，打开百度，输入“React error boundary not working”。剩下的 1% 的人，如果他们足够资深，会开始怀疑人生：“为什么我的代码在本地能跑，上线就崩？为什么我的 try-catch 像个摆设？”

今天，我们就来聊聊怎么在这个充满 Bug 的世界里，建立起一道坚不可摧的防线。我们要讲的不只是怎么把错误“抓”起来，还要讲怎么把后端的“真实堆栈”还原到前端，让你在崩溃的时候，依然能像个侦探一样知道凶手是谁。

第一章：前端错误边界 —— 那个叫“ErrorBoundary”的伪君子

首先，我们得聊聊前端。React 有一套很引以为傲的机制叫“组件化”，它的初衷是让 UI 变成可复用的积木。但问题是，React 是一个声明式的框架，它只负责描述“状态是什么”，而不负责描述“状态是怎么变的”。这导致了一个巨大的盲区：React 无法捕获同步的错误。

如果你在组件的渲染函数里写了一行 const a = b.split(0)，然后 b 是 undefined，React 的虚拟 DOM 会直接崩溃。这时候，React 默认的做法是——罢工。它把整个组件树干掉，你的页面会瞬间变成白板，甚至整个浏览器标签页都可能挂掉。

这时候，ErrorBoundary 闪亮登场了。它不是真的边界，它更像是一个门卫，试图拦截那些试图冲进你组件树的错误。

1.1 类组件的“传统艺能”

最经典的 ErrorBoundary 是一个类组件。它的核心原理很简单：利用 React 的生命周期 getDerivedStateFromError 和 componentDidCatch。

听名字很高大上对吧？其实就是两个回调函数。

// 这是一个非常经典的 ErrorBoundary 实现
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false, error: null, errorInfo: null };
  }

  // 1. 当子组件抛出错误时，React 会调用这个方法
  static getDerivedStateFromError(error) {
    // 更新 state 使下一次渲染能够显示降级后的 UI
    return { hasError: true };
  }

  // 2. 在捕获错误后执行副作用操作（比如记录日志）
  componentDidCatch(error, errorInfo) {
    // 这里通常用来发送错误到后端或 Sentry
    console.error("Error caught by boundary:", error, errorInfo);

    // 保存错误信息到 state，以便我们在 UI 中展示
    this.setState({
      error,
      errorInfo
    });
  }

  render() {
    if (this.state.hasError) {
      // 崩溃后的 UI：你可以放一个 404 页面，或者一个“系统维护中”的弹窗
      return (
        <div style={{ padding: 20, color: 'red', border: '2px solid red' }}>
          <h1>哎呀，出错了！</h1>
          <p>别慌，我已经把现场拍下来了。</p>
          {/* 这是一个 React DevTools 扩展能看到的调试面板 */}
          <details style={{ marginTop: 20 }}>
            <summary>点击查看错误详情</summary>
            <pre>{this.state.errorInfo?.componentStack}</pre>
          </details>
        </div>
      );
    }
    // 正常渲染子组件
    return this.props.children;
  }
}

// 使用方式
function UserProfile({ userId }) {
  const [user, setUser] = React.useState(null);

  React.useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);

  // 这里故意写一个会崩溃的代码，为了测试 ErrorBoundary
  // 如果 user.name 为 undefined，这行代码就会炸
  const name = user.name.toUpperCase(); // 玄学错误

  return <div>{name}'s Profile</div>;
}

// 把它包起来
<ErrorBoundary>
  <UserProfile userId={123} />
</ErrorBoundary>

注意看代码里的注释。 这里有一个巨大的坑：ErrorBoundary 只能捕获同步错误。

如果错误发生在 useEffect、事件处理器（比如 onClick）或者 Promise 回调里，ErrorBoundary 是抓不住的。因为这些都是异步操作，它们发生在渲染周期之外。React 的生命周期就像一个沙箱，只负责把沙子（渲染）运进来，至于沙子在哪里被风吹跑了（异步错误），它是不管的。

1.2 Hooks 的“新式武器”

既然类组件那么麻烦（还要继承、还要写静态方法），React 16.9+ 推出了 useErrorBoundary 这个自定义 Hook。它本质上还是封装了上面的类组件逻辑，但是让你可以在函数组件里直接用。

import { useErrorBoundary } from 'react-error-boundary';

function UserProfile({ userId }) {
  const { showBoundary, ComponentErrorBoundary } = useErrorBoundary({
    FallbackComponent: ({ error }) => (
      <div className="error-fallback">
        <h1>出错了</h1>
        <p>{error.message}</p>
      </div>
    )
  });

  // 模拟异步错误
  const handleClick = () => {
    fetch('/api/user/undefined').then(() => {
      // 这里会炸
      console.log("Success");
    });
  };

  return (
    <div>
      <button onClick={handleClick}>触发错误</button>
      <ComponentErrorBoundary>
        <UserProfileContent userId={userId} />
      </ComponentErrorBoundary>
    </div>
  );
}

但是！ 即便用了 useErrorBoundary，你依然无法捕获所有错误。比如在 useEffect 里抛出的错误，依然会被吞掉。为什么？因为 React 的 Hooks 规则规定，Hooks 必须在顶层调用，不能在条件语句里调用。如果你在 useEffect 里 throw new Error()，React 的调度器会直接把这个错误当作“未处理的 Promise 拒绝”处理，而不是渲染错误。

所以，前端 ErrorBoundary 只能拦截渲染时的同步错误。剩下的异步错误，我们得靠别的手段。

第二章：后端错误处理 —— Node.js 的“裸奔”现实

好了，前端搞定了一半，现在我们看后端。如果你用的是 Node.js（Express, Koa, NestJS 等），你会发现一个恐怖的事实：后端根本没有 Error Boundary！

在浏览器里，JS 引擎（V8）会捕获错误并显示给用户。但在 Node.js 里，如果你在顶层代码写了一行 throw new Error("Boom")，或者在你的 Controller 里抛出了一个没被 try-catch 包裹的错误，整个 Node.js 进程就会直接崩掉。

整个服务器会挂，所有正在等待请求的用户都会收到 502 Bad Gateway。

2.1 全局中间件 —— 你的救命稻草

为了防止服务器炸服，我们必须在后端设置“全局中间件”。这就像是给服务器穿了一层防弹衣。

在 Express 中，我们需要在路由注册之前注册一个全局错误处理中间件。

// app.js (Express 示例)
const express = require('express');
const app = express();

// 1. 全局错误处理中间件
// 注意：这个中间件必须放在路由注册之前！
// 它的签名必须是 (err, req, res, next)
app.use((err, req, res, next) => {
  console.error('Error caught by backend:', err);

  // 这里是堆栈还原的关键：我们要把堆栈信息发出去
  const errorResponse = {
    message: err.message || 'Internal Server Error',
    stack: process.env.NODE_ENV === 'development' ? err.stack : undefined, // 生产环境别把堆栈给前端看，太危险
    timestamp: new Date().toISOString()
  };

  res.status(500).json(errorResponse);
});

// 2. 路由示例
app.get('/api/data', (req, res) => {
  // 模拟一个后端错误
  if (Math.random() > 0.5) {
    throw new Error('Database connection failed!'); // 这行代码如果没被 catch，服务器就挂了
  }

  res.json({ status: 'ok', data: [1, 2, 3] });
});

app.listen(3000, () => console.log('Server running on port 3000'));

2.2 未捕获的异常 —— 进程级别的恐慌

除了路由里的错误，还有两种情况会让 Node 进程崩溃：

unhandledRejection：Promise 被 reject 了，但没有 catch。
uncaughtException：代码里 throw 了错误，但没有被任何地方 catch。

这时候，你的服务器就真的“炸”了。为了防止这种情况，我们需要监听这两个事件。

// 进程级别的监听
process.on('uncaughtException', (err) => {
  console.error('Uncaught Exception:', err);
  // 在这里，你可以触发 Sentry 的告警，或者发送邮件给运维
  // 注意：Node.js 官方建议在这种时候退出进程，因为你无法保证程序还能正常运行
  process.exit(1);
});

process.on('unhandledRejection', (reason, promise) => {
  console.error('Unhandled Rejection at:', promise, 'reason:', reason);
  process.exit(1);
});

第三章：全栈桥梁 —— 从后端到前端的“越狱”

现在我们有了前端的 ErrorBoundary（抓同步渲染错误）和后端的 Global Handler（抓同步逻辑错误）。但是，这还不够。

3.1 异步错误的传递

假设用户在前端点击了一个按钮，这个按钮调用了后端 API：
fetch('/api/delete-user')。

如果后端数据库挂了，抛出了错误，后端中间件捕获了它，返回了 500 状态码和 JSON 响应。前端收到了这个响应，但是……前端没有错误！

因为这是一个 Promise，React 不知道这里发生了错误。ErrorBoundary 不会触发，UI 也不会变红。用户只会觉得“怎么没反应？”

这时候，我们需要一个全栈的桥梁。

3.2 全局 Fetch 拦截器

我们需要在前端封装一个 fetch，或者在 Axios 的拦截器里做文章。我们要告诉 React：“嘿，如果收到 500 错误，或者是 HTTP 错误，就把它当成一个全局错误抛出来。”

// 全局 fetch 封装
const originalFetch = window.fetch;

window.fetch = async (...args) => {
  const response = await originalFetch(...args);

  // 如果状态码不是 2xx，说明出错了
  if (!response.ok) {
    const error = new Error(`HTTP Error: ${response.status}`);
    error.response = response; // 保存响应体
    error.status = response.status;

    // 关键步骤：抛出错误，让 ErrorBoundary 或全局错误处理器去处理
    throw error;
  }

  return response;
};

// 配合 React 的 ErrorBoundary 使用
// 这样，任何 API 请求失败，都会触发 ErrorBoundary

但是，这有个问题。window.fetch 抛出的错误是 HTTP 错误，而 ErrorBoundary 捕获的是 JS 运行时错误。React 默认的 ErrorBoundary 只能捕获 Error 对象。

为了让它们统一，我们需要一个自定义的 Hook，把 HTTP 错误包装成 JS 错误。

function useGlobalErrorHandler() {
  React.useEffect(() => {
    const errorHandler = (event, error) => {
      console.error('Global Error:', error);
      // 在这里，你可以把错误发送到后端日志服务
      // sendToLogService(error);

      // 如果你有一个全局的 ErrorBoundary 组件，你可以手动触发它的状态
      // 但通常我们会直接让 ErrorBoundary 捕获 window.onerror
    };

    window.addEventListener('error', errorHandler);
    return () => window.removeEventListener('error', errorHandler);
  }, []);
}

第四章：堆栈还原 —— 破解“黑盒”之谜

好了，现在我们有了前端捕获和后端捕获。但是，React 的 componentStack 往往非常浅，它只显示你在哪个组件里写了错误代码，但不知道这个组件是在哪个函数里调用的，更不知道数据来源是哪里。

而 Node.js 的 err.stack 就很详细，它列出了从 Controller -> Service -> Repository -> Database Driver 的完整调用链。

堆栈还原，就是要把后端那个长长的、包含业务逻辑的堆栈，翻译给前端看，或者在前端展示出来。

4.1 构建一个“崩溃报告单”

想象一下，你的应用崩溃了。你不想只看到 Error: something went wrong，你想看到：

前端上下文：在哪个页面（路由）？
后端上下文：哪个 API 接口报错？具体是哪一行代码？
用户环境：浏览器版本、操作系统、用户 ID。

我们需要在后端写一个专门的接口，专门用来“查案”。

// backend/routes/log.js
const router = express.Router();

// 这是一个“查案”接口
// 当前端崩溃时，前端可以调用这个接口，传入错误 ID 或时间戳
router.post('/api/logs/retrieve', async (req, res) => {
  const { errorId, timestamp } = req.body;

  // 从数据库（比如 MongoDB）里查日志
  const log = await LogModel.findOne({ 
    errorId, 
    timestamp 
  });

  if (!log) {
    return res.status(404).json({ message: 'Log not found' });
  }

  // 返回还原后的堆栈信息
  res.json({
    originalStack: log.fullStack, // 完整的后端堆栈
    frontendContext: log.frontendContext, // 前端报错时的快照
    userAgent: log.userAgent
  });
});

4.2 前端崩溃 UI 设计

现在，我们回到前端的 ErrorBoundary。当它捕获到错误时，不要直接显示 hasError: true，我们要设计一个“交互式”的错误页面。

// CrashReportUI.jsx
function CrashReportUI({ error, errorInfo }) {
  const [stackLog, setStackLog] = React.useState(null);
  const [loading, setLoading] = React.useState(false);
  const [showBackendDetails, setShowBackendDetails] = React.useState(false);

  // 当用户点击“查看后端详情”时，调用后端接口
  const handleFetchBackendDetails = async () => {
    setLoading(true);
    try {
      const response = await fetch('/api/logs/retrieve', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          errorId: error.errorId, // 假设我们在 ErrorBoundary 里把 errorId 存下来了
          timestamp: new Date().toISOString()
        })
      });
      const data = await response.json();
      setStackLog(data);
      setShowBackendDetails(true);
    } catch (err) {
      console.error('Failed to fetch backend logs', err);
    } finally {
      setLoading(false);
    }
  };

  return (
    <div className="crash-page">
      <h1>系统崩溃了 (500 Internal Server Error)</h1>
      <p>别担心，我们正在努力修复。您可以查看以下信息帮助我们排查问题。</p>

      {/* 前端堆栈 */}
      <details>
        <summary>前端堆栈 (点击查看)</summary>
        <pre>{errorInfo?.componentStack}</pre>
      </details>

      {/* 后端堆栈还原按钮 */}
      <button 
        onClick={handleFetchBackendDetails} 
        disabled={loading}
        style={{ marginTop: 20, padding: 10 }}
      >
        {loading ? '正在从服务器调取证据...' : '查看后端详细堆栈'}
      </button>

      {/* 后端堆栈还原结果 */}
      {showBackendDetails && stackLog && (
        <div className="backend-stack-panel">
          <h3>后端真实堆栈还原</h3>
          <p><strong>API 接口:</strong> {stackLog.originalStack.match(/at.*api/(.*?)(.*)/)?.[1] || 'Unknown'}</p>
          <pre>{stackLog.originalStack}</pre>
        </div>
      )}
    </div>
  );
}

4.3 如何将前端错误 ID 传给后端？

这是最关键的一步。当 ErrorBoundary 捕获到错误时，我们要生成一个唯一的 errorId，并把它发送到后端。

// ErrorBoundary.js (修改版)
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false, error: null, errorInfo: null, errorId: null };
  }

  static getDerivedStateFromError(error) {
    // 生成一个唯一的 ID，用于关联前后端日志
    const errorId = `ERR-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;
    return { hasError: true, error, errorId };
  }

  componentDidCatch(error, errorInfo) {
    // 立即发送到后端
    fetch('/api/logs/create', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        errorId: this.state.errorId,
        message: error.message,
        stack: error.stack, // 前端堆栈
        componentStack: errorInfo.componentStack,
        userAgent: navigator.userAgent,
        url: window.location.href
      })
    }).catch(console.error); // 发送日志失败不能影响页面崩溃
  }

  render() {
    if (this.state.hasError) {
      return <CrashReportUI error={this.state.error} errorInfo={this.state.errorInfo} />;
    }
    return this.props.children;
  }
}

堆栈还原的奥秘：
通过 errorId，我们将前端的“报案人”和后端的“现场勘查报告”连接了起来。前端只看到 componentStack（很浅），后端看到 fullStack（很深）。用户点击按钮，前端去后端“查案”，后端把那个长长的、包含业务逻辑的堆栈吐出来，前端展示给用户。

第五章：服务端渲染 (SSR) 的噩梦 —— Hydration Failed

React 全栈开发，怎么能不提 Next.js 或 Remix？SSR（服务端渲染）虽然性能好，但它引入了一个新的错误类型：Hydration Mismatch（水合不匹配）。

这就像你在餐厅点了菜，服务员端上来的是一份套餐，你却发现你的菜单上写的是“单点”。React 会报错：Hydration failed because the initial UI does not match what was rendered on the server.

5.1 Hydration 错误的特殊性

Hydration 错误非常难排查，因为它通常发生在初始加载时。

// 这是一个典型的 Hydration 错误场景
function Counter() {
  const [count, setCount] = React.useState(null); // 初始值是 null

  // 如果后端返回的数据是 null，而前端默认是 0，就会报错
  // useEffect 是在 Hydration 之后才执行的
  React.useEffect(() => {
    fetch('/api/count').then(res => res.json()).then(setCount);
  }, []);

  // 渲染逻辑
  return (
    <div>
      {/* 这里的逻辑依赖于 count */}
      <h1>Count: {count === null ? 'Loading...' : count}</h1>
      <button onClick={() => setCount(c => c + 1)}>Add</button>
    </div>
  );
}

5.2 捕获 Hydration 错误

React 18 引入了 startTransition，但对于 Hydration 错误，我们依然需要 ErrorBoundary。但是，由于 Hydration 是在服务器端发生的，前端的 ErrorBoundary 可能抓不到。

我们需要在服务端渲染逻辑里捕获它。

// Next.js 或 SSR 框架的入口文件
function renderApp() {
  try {
    return ReactDOMServer.renderToString(<App />);
  } catch (err) {
    // 捕获 SSR 错误
    console.error('SSR Error:', err);
    return `<div>An error occurred during SSR: ${err.message}</div>`;
  }
}

堆栈还原在这里的作用：
SSR 的错误堆栈通常非常长，因为它包含了 Node.js 的模块加载过程。我们需要在服务端捕获这个堆栈，并把它序列化到 HTML 的某个隐藏标签里，或者发送到前端。

// 在 ErrorBoundary 中，我们不仅捕获客户端错误，也尝试捕获 SSR 错误
class ErrorBoundary extends React.Component {
  // ... 其他代码

  componentDidCatch(error, errorInfo) {
    // 如果是 Hydration 错误，堆栈信息会包含 'hydrate' 字样
    if (error.message.includes('Hydration')) {
      // 发送特殊标记到后端
      fetch('/api/logs/hydration', {
        method: 'POST',
        body: JSON.stringify({ error: error.stack })
      });
    }
  }
}

第六章：实战演练 —— 完整的全栈错误处理系统

现在，让我们把所有的东西拼起来。我们要构建一个系统，它能处理：

同步渲染错误。
异步 API 错误。
SSR Hydration 错误。
后端进程崩溃。
堆栈还原。

6.1 架构图解

想象一下这个流程：

用户操作 -> 点击按钮。
前端 -> 调用 API。
后端 -> 执行业务逻辑 -> 抛出 Error("User not found")。
后端 -> Global Middleware 捕获 -> 生成 errorId -> 记录日志（包含完整堆栈） -> 返回 500 JSON。
前端 -> Fetch 拦截器捕获 HTTP 500 -> 包装成 JS Error -> 抛出。
React -> ErrorBoundary 捕获 -> 渲染 UI -> 显示“出错了”。
用户 -> 点击“查看后端堆栈”。
前端 -> 发送 errorId 到后端。
后端 -> 查询数据库 -> 返回完整堆栈。
前端 -> 展示完整堆栈。

6.2 代码整合示例

后端 (Node.js + Express):

// server.js
const express = require('express');
const { createLogger, transports } = require('winston'); // 假装有个日志库

const app = express();

// 全局错误处理中间件
app.use((err, req, res, next) => {
  const errorId = Math.random().toString(36).substr(2, 9);

  // 记录到数据库或文件
  logService.save({
    errorId,
    message: err.message,
    stack: err.stack, // 这是完整的 Node.js 堆栈
    url: req.url,
    method: req.method
  });

  res.status(500).json({ errorId, message: err.message });
});

// 模拟数据库报错的接口
app.get('/api/crash', (req, res, next) => {
  setTimeout(() => {
    throw new Error('Database connection timeout! This is the real stack trace.');
  }, 100);
});

app.listen(3000);

前端 (React + Fetch):

// ErrorBoundary.jsx
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false, error: null, errorId: null };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // 生成 ID 并发送日志
    const errorId = Math.random().toString(36).substr(2, 9);
    this.setState({ error, errorId });

    fetch('/api/logs', {
      method: 'POST',
      body: JSON.stringify({
        errorId,
        message: error.message,
        stack: error.stack, // 前端堆栈
        componentStack: errorInfo.componentStack
      })
    });
  }

  render() {
    if (this.state.hasError) {
      return <CrashReport errorId={this.state.errorId} />;
    }
    return this.props.children;
  }
}

// CrashReport.jsx
function CrashReport({ errorId }) {
  const [backendStack, setBackendStack] = React.useState(null);

  React.useEffect(() => {
    if (!errorId) return;

    // 1. 尝试从后端获取完整堆栈
    fetch(`/api/logs/${errorId}`)
      .then(res => res.json())
      .then(data => setBackendStack(data.stack))
      .catch(() => console.error('Failed to fetch backend stack'));
  }, [errorId]);

  return (
    <div>
      <h1>Oops! Something went wrong.</h1>
      <p>Error ID: {errorId}</p>

      {/* 前端堆栈 */}
      <details>
        <summary>Frontend Stack</summary>
        <pre>{window.__REACT_DEVTOOLS_GLOBAL_HOOK__?.render ? 'React DevTools Stack' : 'N/A'}</pre>
      </details>

      {/* 后端堆栈还原 */}
      {backendStack && (
        <div style={{ border: '1px solid #ccc', padding: 10, marginTop: 20 }}>
          <h3>Backend Stack Trace (Restored)</h3>
          <pre style={{ whiteSpace: 'pre-wrap' }}>{backendStack}</pre>
        </div>
      )}
    </div>
  );
}

第七章：高级话题与避坑指南

讲了这么多，还有一些“玄学”的地方需要注意。

7.1 异步组件的错误

React 16.6 引入了 React.lazy 和 Suspense。如果你懒加载了一个组件，而这个组件渲染时抛出了错误，Suspense 会fallback，但如果你没有设置 fallback，或者 fallback 本身也崩溃了，那整个页面就没了。

// 正确的做法
const HeavyComponent = React.lazy(() => import('./HeavyComponent'));

function App() {
  return (
    <React.Suspense fallback={<div>Loading...</div>}>
      <HeavyComponent />
    </React.Suspense>
  );
}

7.2 错误边界不能捕获的事件处理器

记住，onClick、onSubmit 里的错误，ErrorBoundary 捕获不了。你必须自己在事件处理函数里写 try/catch。

function MyForm() {
  const handleSubmit = (e) => {
    try {
      // 业务逻辑
    } catch (err) {
      // 必须手动处理
      console.error('Form error:', err);
      alert('提交失败，请重试');
    }
  };

  return <form onSubmit={handleSubmit}>...</form>;
}

7.3 堆栈还原的性能开销

频繁地发送错误日志到后端，会给服务器造成压力。在生产环境中，我们应该设置一个阈值：只有当错误发生频率超过每分钟 10 次，或者错误类型是 Critical（如数据库连接失败）时，才发送完整堆栈到日志系统。

7.4 环境隔离

永远不要在生产环境的代码里把完整的 err.stack 返回给前端用户。这是安全大忌！你不想让黑客知道你的服务器架构、使用的框架版本以及代码里的敏感逻辑。

// 错误示例
if (process.env.NODE_ENV === 'production') {
  res.json({ message: 'Internal Server Error' }); // 不给堆栈
} else {
  res.json({ message: err.message, stack: err.stack }); // 开发环境给堆栈
}

结语：从“救火”到“防火”

各位同学，React 全栈开发就像是在走钢丝。前端是惊险的独木桥，后端是深不见底的峡谷。

我们构建 ErrorBoundary，不是为了把错误掩盖过去，而是为了在错误发生时，能够优雅地降级，能够清晰地还原现场。

当你下次再遇到“白屏”或者“炸服”的时候，不要只顾着骂人。深吸一口气，看看你的前端堆栈，然后调用你的后端接口，去那个“后端堆栈还原”的宝箱里，找到那个让你崩溃的罪魁祸首。

记住，代码会出错，这是常态。但优秀的工程师，能让错误变成故事，而不是事故。

祝大家代码永无 Bug，堆栈清晰可读！

（讲座结束，欢迎大家提问，如果有谁还搞不懂 getDerivedStateFromError，我们可以私下再聊。）

P.S. 下次如果有人问你“堆栈还原”是什么，你就告诉他：“堆栈还原就是让后端那个高冷的程序员，通过一根网线，告诉前端那个懵懂的用户：‘嘿，刚才是你妈叫你写的代码炸了’。”