开发记录：路由缓存与布局编排重构

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

为什么在 M5-6 补路由缓存与布局

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt、状态管理、复杂交互和认证权限，但在真实项目里，还有一条非常高频的横向主线会不断影响它们：应用壳层与路由页面的关系。

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

• 根组件会越来越重
• 页面缓存会变成无法解释的模板技巧
• 布局切换会散落到页面内部
• 页面重新进入和再次激活的行为会越来越不稳定

所以 M5-6 选择路由缓存与布局，是为了把“应用壳层、路由出口、缓存策略”这一条非常常见的横向架构线补齐。

这轮做了什么

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

• 新增路由缓存与布局编排案例文档
• 新增 M5-6 任务拆解文档
• 新增 M5-6 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将路由与布局型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲壳层边界，再讲缓存写法

这轮没有把重点放在“keep-alive 怎么用”，而是放在：

• 根应用到底应不应该继续长成超级容器
• 布局切换为什么应该走路由协议
• 缓存策略为什么必须显式化
• 页面激活与失活为什么不能再混同为挂载与卸载

决策二：选 vue-sell-app 的 App.vue 作为案例来源

虽然这个示例不大，但它非常适合作为壳层重构的起点，因为它同时具备：

• 顶部公共区域
• tab 导航
• 路由出口
• keep-alive 页面缓存入口

它很适合作为“从早期根组件壳层，走向现代布局与缓存边界”的过渡案例。

决策三：用现代 Vue 3 路由表达重写方法沉淀

原始素材来自 Vue 2，但这轮文档沉淀时，统一改用更适合当前项目的方法表达：

• RouterView 插槽
• KeepAlive 显式边界
• route.meta.layout / route.meta.keepAlive
• activated / deactivated 的运行时分层

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

本轮自测怎么做

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

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

本轮结果

M5-6 完成后，当前方法库已经不只覆盖状态、渲染、交互和认证问题，也开始覆盖另一条非常基础的架构主线：应用壳层与路由页面的分工。

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

• 后台工作台布局体系
• 多 tab 页缓存设计
• 页面激活恢复策略
• Nuxt 布局与页面边界
• 路由元信息驱动的页面组织

都已经有了稳定挂载点。