Error Boundaries 仅捕获子组件树在 render、getDerivedStateFromError、componentDidCatch 中同步抛出的错误，不捕获异步操作、事件处理器、服务端渲染及自身 render 错误；需结合受控降级状态、结构化上报与智能重试策略实现可靠错误处理。
React 16+ 中 Error Boundaries 的捕获边界到底在哪
Error Boundaries 不会捕获异步操作（如 setTimeout、Promise.then）、服务端渲染错误、事件处理函数内抛出的错误，也不会捕获自身 render 方法里的错误（否则会无限循环）。它只捕获子组件树在 render、getDerivedStateFromError、componentDidCatch 过程中同步抛出的 JS 错误。
这意味着：如果你在 onClick 回调里写 throw new Error('boom')，这个错误不会被最近的 Error Boundary 捕获——必须把它包装进 setState 触发的重新渲染流程里，或改用 useEffect + 异步错误兜底逻辑来桥接。
- 推荐把关键 UI 区域（如侧边栏、内容主区、卡片列表）单独包裹成带 Error Boundary 的组件，而不是只在根组件包一层
- 不要在
componentDidCatch中调用this.setState触发同级更新；应触发降级 UI 的状态变更（如isError），且该状态需来自上层可控 state，而非被污染的组件实例 - SSR 场景下，Error Boundary 在服务端不生效，只能靠
try/catch+renderToStaticMarkup降级兜底
如何让 componentDidCatch 同时上报错误并触发自动降级 UI
componentDidCatch 是唯一能拿到 error 和 info（含组件栈）的生命周期，但它的执行时机晚于渲染异常，所以不能靠它“阻止”崩溃，只能做两件事：记录 + 切换 UI 状态。
典型做法是结合一个受控的降级开关（比如 fallbackVisible）和全局监控 SDK（如 Sentry、自研上报接口）：
立即学习“前端免费学习笔记（深入）”；
componentDidCatch(error, info) {
// 上报结构化数据，包含 componentStack
reportError({
message: error.message,
stack: error.stack,
componentStack: info.componentStack,
url: window.location.href
});
// 触发降级 UI（注意：不是 this.setState({ error })，而是通知上层）
this.props.onBoundaryError?.(error);
}
- 避免在
componentDidCatch里直接调用异步上报（如fetch），以防阻塞渲染；应使用setTimeout(() => report(), 0)或queueMicrotask - 降级 UI 最好是轻量静态内容（如「内容加载失败」+ 重试按钮），不要依赖任何外部资源（图片、字体、子组件）
- 如果使用函数组件 +
useErrorBoundary（react-error-boundary 库），注意其resetErrorBoundary只重置本地状态，不恢复被销毁的子组件树；需配合key变更强制重建
自动恢复的关键：什么时候该重试，什么时候该永久禁用
自动恢复不是“定时刷新”，而是对错误类型和发生上下文做判断。例如网络请求失败导致的渲染错误可重试，而 TypeError: Cannot read property 'map' of undefined 很可能说明数据结构已变更，重试无意义。
- 在
onBoundaryError回调中解析error.stack或error.message，匹配已知可恢复模式（如含Failed to fetch、NetworkError） - 对同一错误在 5 分钟内重复出现 ≥3 次，应标记为“疑似稳定故障”，跳过自动重试，转为展示维护提示
- 重试动作必须由用户显式触发（点击按钮）或由路由变化/焦点回到页面等明确信号驱动；禁止
setInterval自动轮询，否则可能放大后端压力 - 利用
localStorage记录最近一次错误时间戳和类型，下次进入页面时决定是否预加载降级态
与全局监控系统对接时最容易漏掉的三个细节
很多团队把错误上报做了，但没打通降级闭环，问题出在数据链路断点上：
- 监控平台报警规则只看
error.message，但实际需要结合componentStack定位到具体组件层级；漏传info.componentStack会导致无法区分是业务组件还是 UI 库内部报错 - 上报时未携带
buildId或commit hash，导致无法关联 sourcemap 还原原始代码行号；构建产物需确保生成并上传对应.map文件 - 未对
error.cause（Chrome 120+）、error.cause?.stack做递归采集，丢失嵌套错误根因（如 Promise 链中深层 reject）
降级不是掩盖错误，而是把不可控的崩溃转化为可控的状态切换；真正难的不是写一个 componentDidCatch，是在错误发生后，还能准确知道它从哪来、影响多广、值不值得再试一次。
