开发记录：异步组件与懒加载降级重构

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

为什么在 M5-8 补异步组件与懒加载

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt、状态管理、复杂交互、认证权限、路由壳层和错误隔离，但在真实项目里，还有一条会反复影响这些内容的横向主线：功能块到底应该什么时候加载、如何占位、失败后如何恢复。

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

• 首屏加载体验越来越碎
• loading / error / timeout 逻辑散在页面里
• 客户端增强模块和普通异步模块混在一起
• 用户看到的只是空白模块或无法解释的失败态

所以 M5-8 选择异步组件与懒加载，是为了把“加载策略、占位边界、失败恢复”这一条非常常见的横向架构线补齐。

这轮做了什么

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

• 新增异步组件与懒加载案例文档
• 新增 M5-8 任务拆解文档
• 新增 M5-8 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将异步加载型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲加载链路边界，再讲 import 语法

这轮没有把重点放在“动态导入怎么写”，而是放在：

• 哪些模块真正值得异步化
• loading / error / timeout 为什么必须统一设计
• 客户端专属异步模块为什么要单独分层
• fallback 与重试为什么必须前置设计

决策二：选 Vue 异步组件源码与 Nuxt ClientOnly 作为案例来源

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

• 异步组件的状态机式加载过程
• loading / error / timeout 的原生思路
• 客户端专属增强模块的加载边界

它很适合作为“从分散 loading 写法，走向系统级异步加载边界”的过渡案例。

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

这轮没有把异步加载理解成“先不显示”，而是把重点放在：

• 用户加载中看到什么
• 模块失败后能做什么
• 页面主体如何与延迟模块解耦

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

本轮自测怎么做

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

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

本轮结果

M5-8 完成后，当前方法库已经不只覆盖状态、渲染、交互、认证、路由和容错问题，也开始覆盖另一条非常基础的系统能力主线：异步加载与占位恢复体验。

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

• 编辑器延迟加载策略
• 图表模块主包拆分
• 地图库与 3D 模块懒加载
• 首屏占位与后续增强协作
• Nuxt 下的客户端增强块设计

都已经有了稳定挂载点。