开发记录：Nuxt组合式能力分层与页面编排重构

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

为什么在 M5-14 补 Nuxt组合式能力分层与页面编排边界

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt 页面数据、状态管理、复杂交互、认证权限、路由壳层、错误隔离、异步加载、Nuxt 运行时边界、Nuxt 响应策略、Nuxt 执行时机、Nuxt 依赖边界和 Nuxt 接口边界，但在真实 Nuxt 项目里，还有一条会持续穿透这些内容的主线：页面虽然已经有了 setup()、有了 composable、也有了 store 和本地接口，但页面编排复杂度本身并没有因为“代码抽出去”就自动消失。

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

• 页面顶层直接拼太多 useXxx()，阅读成本仍然很高
• 页面业务 composable、局部步骤 composable 和 store 职责互相侵入
• 页面数据、SEO、埋点、query 同步和错误恢复分散在不同层次里
• 页面迁移成弹窗、子路由或多布局变体时，很难整体复用原有编排

所以 M5-14 选择 Nuxt 组合式能力分层与页面编排边界，是为了把“页面入口、页面业务 composable、feature 步骤层、store 归属、页面契约协同”这一条非常常见的横向架构线补齐。

这轮做了什么

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

• 新增 Nuxt 组合式能力分层与页面编排案例文档
• 新增 M5-14 任务拆解文档
• 新增 M5-14 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将 Nuxt 页面编排型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲页面编排边界，再讲 composable 数量

这轮没有把重点放在“页面里到底该抽几个 composable”，而是放在：

• 页面顶层应该直接消费哪些稳定入口
• 页面业务 composable 为什么要成为独立一层
• store 为什么不能回收所有页面局部状态
• 页面级副作用为什么应该围绕同一份页面契约协同

决策二：选 Nuxt 自动导入、数据获取和接口边界案例共同作为素材来源

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

• 页面自动导入与公共入口控制
• 页面级取数与渲染数据边界
• 服务端接口契约与页面语义协同
• 生命周期、副作用与页面挂载时机

它很适合作为“从依赖边界，走向页面编排边界”的过渡案例。

决策三：把页面契约、页面编排和局部步骤拆成三层

这轮没有把 composable 继续视作单一抽象，而是把重点放在：

• 页面入口层如何保持语义清晰
• 页面业务 composable 如何收口页面级复杂度
• feature 内部步骤 composable 如何承接局部流程细节

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

本轮自测怎么做

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

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

本轮结果

M5-14 完成后，当前方法库已经不只覆盖状态、渲染、交互、认证、路由、容错、异步加载、运行时边界、响应策略、执行时机、依赖组织和接口治理问题，也开始覆盖 Nuxt 页面本身的一条基础主线：页面入口收口、页面业务 composable 分层、局部步骤能力组织与页面契约驱动编排。

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

• 后台列表页与筛选面板的页面编排模式
• 内容详情页、SEO 和推荐区块的一体化页面入口
• 多步骤表单页、弹窗页和子路由页的业务编排层设计
• 页面级 query 同步、埋点和错误恢复能力收口
• Nuxt 项目级页面业务 composable 治理

都已经有了稳定挂载点。