开发记录：Nuxt中间件与插件注入边界重构

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

为什么在 M5-9 补 Nuxt中间件与插件边界

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt 页面数据、状态管理、复杂交互、认证权限、路由壳层、错误隔离和异步加载，但在真实 Nuxt 项目里，还有一条非常高频的横向主线会不断影响它们：运行时逻辑到底应该放在哪一层。

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

• 请求级逻辑和页面级逻辑混在一起
• 路由准入和服务端鉴权边界不清
• 插件变成全局业务收纳箱
• 页面消费层越来越懂底层运行时顺序

所以 M5-9 选择 Nuxt 中间件与插件边界，是为了把“请求级、导航级、应用级、页面级”这一条非常常见的横向架构线补齐。

这轮做了什么

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

• 新增 Nuxt 中间件与插件注入边界案例文档
• 新增 M5-9 任务拆解文档
• 新增 M5-9 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将 Nuxt 运行时边界型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲运行时职责，再讲目录放置

这轮没有把重点放在“文件应该放哪里”，而是放在：

• 哪些逻辑属于请求级
• 哪些逻辑属于导航级
• 哪些逻辑属于应用级能力注入
• 页面为什么不应该继续理解底层运行时顺序

决策二：选 Nuxt 生命周期与中间件素材作为案例来源

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

• Nitro 中间件
• 路由中间件
• .server / .client / 无后缀插件
• 页面渲染前后的运行时顺序

它很适合作为“从目录级理解，走向职责级理解”的过渡案例。

决策三：把插件注入与页面消费层彻底分开

这轮没有把插件理解成“全局逻辑都能塞进去”的地方，而是把重点放在：

• 插件只负责能力注入
• composable 负责消费能力
• 页面只负责业务装配

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

本轮自测怎么做

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

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

本轮结果

M5-9 完成后，当前方法库已经不只覆盖状态、渲染、交互、认证、路由、容错和异步加载问题，也开始覆盖 Nuxt 运行时本身的一条基础主线：中间件、插件与注入边界。

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

• 全局 API 客户端注入
• 日志与埋点插件组织
• 服务端请求上下文准备
• 路由准入与页面消费协作
• Nuxt 运行时能力治理

都已经有了稳定挂载点。