开发记录：Nuxt生命周期与副作用时机重构

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

为什么在 M5-11 补 Nuxt生命周期与副作用时机

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt 页面数据、状态管理、复杂交互、认证权限、路由壳层、错误隔离、异步加载、Nuxt 运行时边界和 Nuxt 响应策略，但在真实 Nuxt 项目里，还有一条会不断穿透这些内容的横向主线：同一段逻辑到底在什么时候执行。

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

• 服务启动期、单次请求期和客户端挂载期的逻辑越来越混写
• 页面首屏数据和浏览器副作用互相污染
• validate、中间件和页面渲染重复做判断
• 清理逻辑没有落点，最后变成重复监听、重复请求或 hydration 问题

所以 M5-11 选择 Nuxt 生命周期与副作用时机，是为了把“执行分段、数据准备、副作用触发、环境边界、清理恢复”这一条非常常见的横向架构线补齐。

这轮做了什么

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

• 新增 Nuxt 生命周期与副作用时机案例文档
• 新增 M5-11 任务拆解文档
• 新增 M5-11 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将 Nuxt 执行时机型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲执行分段，再讲具体钩子

这轮没有把重点放在“有哪些钩子”，而是放在：

• 哪些逻辑属于启动级、请求级、导航级、渲染级、客户端交互级
• 为什么副作用必须和执行时机绑定
• 为什么清理逻辑必须和副作用写在同一层
• 为什么页面不应该代偿插件和中间件的时机职责

决策二：选 Nuxt 生命周期与水合素材作为案例来源

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

• 服务端与客户端生命周期差异
• Nitro / Nuxt 应用 / 页面渲染的执行顺序
• SSR 渲染与 hydration 的边界
• 副作用、浏览器 API 和清理逻辑的落点

它很适合作为“从知道顺序，走向理解时机边界”的过渡案例。

决策三：把数据准备和副作用触发放到同一套页面语义里

这轮没有把首屏数据和浏览器副作用分开成两套完全独立的话题，而是把重点放在：

• 首屏可见内容应该如何进入 SSR 渲染链路
• 浏览器专属行为应该如何延后到客户端挂载后执行
• 页面如何围绕同一目标组织数据和交互，而不是把所有逻辑塞进顶层

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

本轮自测怎么做

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

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

本轮结果

M5-11 完成后，当前方法库已经不只覆盖状态、渲染、交互、认证、路由、容错、异步加载、运行时边界和响应策略问题，也开始覆盖 Nuxt 执行时机本身的一条基础主线：生命周期分段、SSR 与客户端边界、副作用落点与清理恢复。

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

• 浏览器 SDK 初始化与客户端时机控制
• 页面埋点、副作用和清理链路治理
• SSR 数据准备与客户端行为拆分
• 复杂页面的执行时机编排
• Nuxt 页面级运行时治理

都已经有了稳定挂载点。