很多团队谈前端稳定性时，只盯着一个目标：不要报错。
但真正进入线上环境后，更关键的问题其实是：
- 报错后页面会不会整块白掉
- 用户还能不能继续完成关键操作
- 团队能不能第一时间知道哪里出问题
所以前端错误处理真正要解决的是 3 件事：
- 兜底
- 提示
- 上报
如果你还在补基础，可以先看 前端错误处理与日志指南、Nuxt 错误处理指南 和 代码质量闸门与 CI 集成。
什么时候需要框架，什么时候别上
如果页面只是很薄的静态结构，错误处理重点主要在表单和接口层。
但一旦进入组件化框架场景，错误就不再只是单点问题，而会影响：
- 整块组件树
- 页面局部功能
- 用户当前操作链路
这时，Error Boundary 和 Fallback 就会变成非常重要的兜底层。
错误处理清单 + 上报方案
| 层级 | 要做什么 | 解决什么问题 |
|---|---|---|
| 组件层 | Error Boundary / 局部 fallback | 防止局部崩溃带倒整页 |
| 页面层 | 页面级错误提示和恢复动作 | 防止用户被困在无响应状态 |
| 接口层 | 请求失败提示、重试、兜底文案 | 防止网络错误被误解成业务错误 |
| 监控层 | 错误上报、上下文记录、告警 | 防止问题只在用户那边发生 |
为什么线上可用性靠“兜底 + 观测”
只做 try/catch 的问题在于：
- 你可能只是在静默吞错
- 用户仍然不知道发生了什么
- 团队也没有收到任何信号
真正稳的体系应该是：
- 先避免整页崩溃
- 再给用户清楚反馈
- 同时把错误上下文记录下来
可执行流程：怎么设计 fallback
1. 区分“整页失败”和“局部失败”
不是所有错误都该让整页进入错误页。
例如：
- 评论区加载失败，可以只给局部 fallback
- 支付页核心模块失败，就不能只默默隐藏
2. Fallback 必须告诉用户下一步能做什么
坏 fallback：
- “系统异常”
更好的 fallback：
- “当前模块加载失败，请刷新重试；如仍失败，可返回上一页继续其他操作”
3. 上报时要带上下文
至少记录：
- 页面路径
- 组件位置
- 用户动作阶段
- 接口状态或关键参数
没有上下文的错误日志，通常很难真正定位问题。
失败案例：错误提示做了，但线上仍然难排查
现象
- 页面不会整页崩溃
- 用户也看到了一条报错提示
- 但团队没法稳定复现，也看不到发生条件
根因
- 只做了前端提示，没有错误上报
- 没记录页面路径、组件上下文和用户动作
- 所有错误都被统一成“加载失败”
修复方式
- 保留用户侧 fallback
- 同时将错误信息结构化上报
- 对关键链路单独定义错误分类
这类问题和 网站上线后观测模板、性能指标指南 一起看，会更容易把“稳定性”做成系统能力。
Checklist
- 是否区分了组件级、页面级、接口级错误
- Fallback 是否告诉用户下一步怎么做
- 关键链路错误是否有独立上报
- 错误日志是否带页面、组件和动作上下文
- 是否避免把所有错误都吞成同一类提示
- 是否对高风险流程做了人工回归验证
