前端错误恢复兜底页之外还要保住用户操作一、错误边界不是显示一句“出错了”前端错误恢复常被简化成 ErrorBoundary。组件炸了显示一个兜底页。这样至少不白屏但还不够。用户可能正在填写表单、筛选数据、编辑内容。一个错误兜底把页面全清掉用户操作也丢了体验照样糟糕。错误恢复要考虑状态保留、局部隔离和重试路径。能局部降级就不要整页崩能保留草稿就不要让用户重填。兜底页不是终点只是最后防线。二、按组件风险划分恢复边界页面可以按业务区域设置错误边界。高风险组件单独包起来避免拖垮整页。flowchart TD A[页面] -- B[筛选区] A -- C[图表区 ErrorBoundary] A -- D[表单区 ErrorBoundary] C -- E[局部重试] D -- F[保留草稿]错误边界放太外层恢复粒度太粗放太细代码又会乱。边界要按风险和用户任务划分。三、表单草稿要在错误前保存关键输入可以做本地草稿。错误恢复后重新挂载组件也能恢复用户输入。function saveDraft(key: string, value: unknown) { try { localStorage.setItem(key, JSON.stringify(value)); } catch { // 本地存储失败不能阻断主流程 } }草稿保存要控制频率和敏感字段。密码、密钥、隐私信息不要随便写 localStorage。四、恢复路径要可观测错误发生后系统要记录组件名、错误堆栈、用户路径和恢复动作。用户点击了重试是否成功草稿是否恢复这些都要看。还要区分可恢复错误和不可恢复错误。数据加载失败可以重试代码运行时异常可能需要刷新权限错误则应该引导重新登录或申请权限。兜底文案不能一刀切。最后错误恢复要测试。手动 throw、接口 500、懒加载 chunk 失败、浏览器存储满都要覆盖。别等线上第一次遇到才发现兜底页按钮也报错。恢复还要避免循环崩溃。用户点击重试后如果同一个组件继续抛错系统应该限制重试次数并提供刷新或反馈入口。无限重试只会让错误边界自己变成错误制造机。错误上下文也要脱敏。上报用户路径和表单状态时不能把敏感输入直接送到监控平台。可以记录字段名、长度、校验状态和 hash少传原文。排障需要证据不需要把用户数据裸奔。最后恢复策略要按任务价值分层。只读图表失败可以局部隐藏支付、提交、保存失败必须明确告诉用户状态。前端错误恢复不是统一兜底而是按用户正在做的事保护现场。懒加载 chunk 失败要单独处理。发布后用户还停留在旧 HTML点击新路由时可能加载不到旧 chunk。可以检测 chunk load error提示刷新并保留当前 URL。不要把这种错误和普通组件异常混在一起。错误恢复还要接入发布信息。错误发生时记录前端版本、构建 hash、路由和实验桶。否则灰度发布期间根本不知道是不是新版本导致的异常。最后兜底 UI 也要符合可访问性。错误提示要能被屏幕阅读器读到重试按钮要能键盘聚焦。别让错误页变成另一个体验事故。恢复成功也要记录。用户点击重试后恢复了说明兜底有效多次失败说明需要升级处理。只记录错误发生不记录恢复结果稳定性看板会少半截真相。草稿恢复还要做版本判断。表单结构已经变了旧草稿不能直接灌回去。可以保存 schema 版本版本不匹配时提示用户确认而不是硬塞导致新错误。五、总结前端错误恢复不只是显示兜底页。局部边界、草稿保留、重试路径和恢复观测都要设计。错误不能完全避免但可以避免一个组件拖垮整个任务。前端稳定性不是不出错而是出错后用户还能继续做事。