错误边界与容错架构
错误不是边角问题，而是架构前提
很多前端系统在设计时，默认前提还是：
功能正常、接口正常、脚本正常、用户环境正常。
这在本地开发阶段很自然。
一到生产环境，就会立刻暴露问题。
真实世界里，前端应用经常会遇到：
- API 超时
- 数据格式异常
- 第三方脚本失败
- 浏览器扩展干扰
- 资源加载中断
- 用户设备性能极差
- 框架层渲染错误
所以容错架构真正要回答的，不是“要不要做错误处理”。
而是：
当错误必然发生时，系统怎样把损害限制在最小范围内。
如果要用一句最核心的话概括：
错误边界和容错架构的目标，不是让错误消失，而是让错误的爆炸半径可控。
为什么 Error Boundary 不能被理解成“React 错误组件”
很多人第一次接触 Error Boundary，会把它理解成：
React 提供的一个错误 UI 组件。
这个理解太浅。
更准确的说法应该是：
Error Boundary 是组件树里的隔离层，用来防止局部渲染错误拖垮更大范围的 UI。
这就意味着，它的价值不在于 fallback 长什么样。
而在于：
- 边界放在哪里
- 哪些功能应该被隔离
- 错误发生后谁负责恢复
如果只会写 <ErrorBoundary fallback={...}>，但不知道边界怎么划，这个 topic 就还没真正掌握。
什么叫“爆炸半径最小化”
可以先把这个概念讲得非常朴素：
一个评论组件出错，不应该把整个文章页一起带崩。
一个侧边栏 widget 出错，不应该让主内容完全消失。
一个局部功能失败，不应该让整站只剩白屏。
这就是错误边界设计的核心目标。
它听起来像常识。
但很多系统没有做到。
因为没有人真正把它当成架构问题来设计。
Error Boundary 分层，为什么不能一层糊到底
最常见的反应是：
那我在最顶层包一个 Error Boundary 不就行了？
这当然比没有好。
但只放一个顶层边界，会失去 Error Boundary 最大的价值。
因为它会把所有错误都收敛成：
整个应用一起挂掉。
更成熟的方式是分层。
例如：
- App 级：保证最坏情况下仍然有全局兜底
- Layout 级：保证某块大区域失败时，不拖垮其余区域
- Feature 级：保证某个业务模块出错时可以局部退化
这样做的本质是把系统从“全有或全无”，改成“局部可损坏、整体仍可用”。
一个更实用的边界划分思路
App 级边界
这是最后兜底。
它存在的目的不是为了优雅。
而是为了防止完全白屏。
这一层的 fallback 往往很简单：
- 报错说明
- 刷新按钮
- 可能的联系支持入口
Layout 级边界
这一层适合放在：
- 主布局
- 侧边栏
- 仪表盘区域
- 内容区与工具区之间
它的意义在于：
一个区域失败时，其他区域仍然可用。
Feature 级边界
这是最值得认真设计的一层。
例如：
- 评论区
- 推荐模块
- 图表卡片
- 富文本编辑器
这些功能失败后，页面主目标不一定要一起失败。
所以它们很适合局部边界。
Error Boundary 解决的是什么错误，不能解决什么错误
这是非常容易被讲错的地方。
React Error Boundary 不是“前端错误全捕获器”。
它主要处理的是渲染阶段、生命周期等组件树内部的错误。
它并不能自动替你处理：
- 所有异步请求错误
- 事件处理函数里的所有异常
- 服务端错误
- 资源加载失败的所有情况
如果把它讲成“React 里有边界，所以错误就都兜住了”，会严重误导团队。
更成熟的表达应该是：
Error Boundary 只覆盖组件树中的一类错误，真正的前端容错架构必须把异步、资源、网络和监控层一起纳入设计。
为什么全局错误捕获依然重要
React 层的边界不够，浏览器层和运行时层仍然需要补。
常见的全局错误入口包括：
window.onerrorunhandledrejection- 资源加载错误
这些入口的价值在于：
即使错误没有优雅恢复，你至少还能：
- 知道它发生了
- 上报上下文
- 做最小级别的用户提示
否则最糟糕的情况是：
用户看到东西不对劲，但系统自己毫无感知。
资源错误为什么不能被忽略
很多团队把错误处理集中在：
- JS 运行异常
- API 失败
但真实用户环境里，资源错误同样高频。
例如：
- 图片加载失败
- 动态脚本 404
- 第三方 SDK 没拉下来
- chunk 加载失败
这类错误很容易把页面搞成：
- 半可用
- 半空白
- 行为怪异
所以成熟系统会把资源错误也纳入：
- 上报
- fallback
- 重试或提示
“优雅降级”到底是什么意思
优雅降级最容易被写成一个很漂亮但空的词。
更有用的理解是：
当理想能力不可用时，系统是否还能保留核心目标路径。
例如：
- 实时搜索挂了，但还能普通搜索
- 推荐模块挂了，但主内容仍然能看
- 图表组件挂了，但至少能看到核心数字
这说明优雅降级不是“把错误藏起来”。
而是：
在失败条件下，保住最重要的用户任务。
Retry 不是什么场景都该加
很多团队发现请求失败后，第一反应就是重试。
这并不总是正确。
重试策略要回答几个问题：
- 失败是暂时性的还是确定性的
- 请求是不是幂等
- 用户是否已经在等待中
- 连续重试会不会放大系统压力
所以 retry with backoff 不是默认模板。
它是针对一类“有机会恢复”的错误场景的策略。
Circuit Breaker 为什么对前端也有意义
很多人会把熔断理解成纯后端概念。
其实前端也有类似价值。
如果某个下游服务持续失败，前端不停重试可能只会：
- 放大噪音
- 拖慢体验
- 进一步压垮系统
所以某些高频失败场景下，前端也应该有：
- 暂停进一步请求
- 给用户明确提示
- 等待恢复条件
这种“停止盲目重试”的能力。
监控体系为什么不能和边界设计分开
Error Boundary 只能决定：
用户眼前如何不完全崩掉。
但它不告诉团队：
- 问题有多严重
- 影响了多少用户
- 哪些版本最糟
- 哪个模块最常出错
这正是监控平台存在的意义。
所以成熟团队谈错误边界，通常会一起谈：
- 错误上报
- release 归因
- source map
- issue 聚合
- session replay
因为“能兜住”和“能定位”是两条必须同时成立的链路。
为什么 fallback UI 不是文案题，而是产品题
很多团队对 fallback 的关注停在：
报错文案写什么。
这太窄了。
真正需要设计的是：
- 用户此刻最想完成什么
- 系统还能保留什么路径
- 是否能刷新局部而不是全页
- 是否能恢复上一次状态
如果这些没想清楚，一个再漂亮的“出错了，请稍后再试”也只是表面安慰。
中国互联网语境里为什么容错架构往往更像“交付能力”
中国互联网产品常常面对：
- 高频活动流量
- 复杂第三方接入
- 多业务模块拼装
- WebView 环境
- 弱网和中低端设备
这使得前端错误很多时候不是极端情况。
而是交付现实的一部分。
所以在中国语境里，容错做得好，常常意味着：
业务高压下还能尽量稳住核心路径。
它不只是代码质量问题。
也是交付韧性问题。
海外语境里为什么错误治理更容易和 observability 绑在一起
海外很多 SaaS 和协作产品的前端系统，会更强调：
- 可观测性
- release 健康度
- 用户会话关联
- 前后端联动排障
所以错误边界在那边很少被单独当作组件技巧。
更常见的是把它放进：
- Sentry
- Datadog RUM
- session replay
- release tracing
这类完整体系里讨论。
面试或技术分享里怎么讲更成熟
一个更成熟的表达可以是：
Error Boundary 的核心价值不是显示一个 fallback，而是控制前端错误的爆炸半径。它只覆盖组件树中的一部分错误，因此真正的前端容错架构还必须把全局错误捕获、资源失败、网络降级、重试策略和错误监控一起设计进来。
成熟系统的目标不是“永不出错”，而是局部失败时整体仍可用，且团队能快速感知、定位和恢复问题。
实践建议
实践一：给一个复杂页面画边界图
明确：
- 哪一层是全局兜底
- 哪些模块适合 feature boundary
- 哪些区域失败后不能拖垮全页
实践二：故意制造 3 类错误
- 渲染错误
- Promise 未处理错误
- 资源加载失败
观察：
- 各自能被谁捕获
- 用户界面会发生什么
- 上报链路有没有补齐
实践三：把一个“整页白屏”的页面改成“局部可失败”
这个练习会直接帮助你建立错误边界的空间感。