开发记录：错误边界与客户端降级重构

这篇开发记录用于复盘 M5-7 的背景、目标、执行过程和最终结果。

为什么在 M5-7 补错误边界与降级

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt、状态管理、复杂交互、认证权限和路由壳层，但在真实项目里，还有一条很关键的横向主线会反复影响它们：故障发生后页面是否还能保持可用。

只要这条链路没有收口，前面任何一类场景都会逐渐出现问题：

• 客户端专属组件混进 SSR 路径
• 局部模块报错导致整页受影响
• fallback 内容散在各个组件里无法复用
• 用户遇到错误后没有统一恢复路径

所以 M5-7 选择错误边界与降级，是为了把“运行环境边界、局部错误隔离、fallback 与恢复动作”这一条非常常见的横向架构线补齐。

这轮做了什么

这轮主要完成了这些事情：

• 新增错误边界与客户端降级案例文档
• 新增 M5-7 任务拆解文档
• 新增 M5-7 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将容错与降级型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲故障隔离边界，再讲组件报错写法

这轮没有把重点放在“某个组件怎么捕获异常”，而是放在：

• 哪些问题属于运行环境边界
• 哪些问题属于局部模块失败
• 哪些问题应该升级成页面级故障
• fallback 与恢复动作为什么要统一设计

决策二：选 Nuxt 的 ClientOnly 与 NuxtErrorBoundary 作为案例来源

这组素材非常适合作为案例来源，因为它刚好覆盖了：

• 客户端专属渲染边界
• 组件树级错误隔离
• SSR / CSR 切换下的降级路径

它很适合作为“从分散兜底写法，走向系统级容错边界”的过渡案例。

决策三：把降级内容和恢复动作一起纳入方法表达

这轮没有把降级理解成“先不渲染”，而是把重点放在：

• fallback 应该展示什么
• 用户遇错后还能做什么
• 页面主体如何与高风险模块解耦

这样新案例就能直接挂到当前已经形成的统一框架里。

本轮自测怎么做

这轮仍然只修改文档，因此自测继续聚焦文档完整性：

• 检查新增 Markdown 文件是否生成成功
• 检查本地链接是否全部可解析
• 检查入口页、导航图和总框架是否已经接入新案例
• 检查 M5-7 的任务拆解、详细设计和开发记录是否齐全

本轮结果

M5-7 完成后，当前方法库已经不只覆盖状态、渲染、交互、认证和路由壳层问题，也开始覆盖另一条非常基础的系统能力主线：错误隔离与页面可用性保护。

这意味着后续如果继续扩展：

• 富文本编辑器兜底
• 图表模块降级展示
• 客户端增强模块延迟挂载
• 页面级错误页与局部错误边界协作
• Nuxt 容错与恢复体验设计

都已经有了稳定挂载点。