开发记录：状态管理与 Pinia 迁移重构

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

为什么在 M5-3 补状态管理

前面的案例已经覆盖了页面、基础组件、SSR 和 Nuxt 页面边界，但这些内容有一个共同底层：状态中心。

只要全局状态边界不清楚，前面任何一类场景都会逐渐出现问题：

• 页面层会越来越重
• composable 会和 store 边界模糊
• SSR / hydration 会变得更难稳定
• Nuxt 页面数据和本地交互状态会混在一起

所以 M5-3 选择状态管理，是为了把这些案例底层共用的一条线补齐。

这轮做了什么

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

• 新增 Vuex / Pinia 状态管理案例文档
• 新增 M5-3 任务拆解文档
• 新增 M5-3 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将状态管理型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲状态边界，再讲迁移语法

这轮没有把重点放在“Pinia 的 API 长什么样”，而是放在：

• 哪些状态应该全局化
• store 应该怎么按业务域拆分
• action 里的副作用应该如何分层
• 为什么迁移前应该先做边界收口

决策二：选 vue-todo 的 store 作为案例来源

因为这个示例同时具备：

• 相对完整的 Vuex 分层
• 真正的业务状态（todos / user / loading）
• 明显可以继续收口的边界问题

它很适合作为“从旧式 Vuex 走向现代 Pinia 结构”的过渡案例。

决策三：补入官方 Pinia 迁移与 Nuxt 集成视角

为了让这篇案例不只停留在本地旧示例层面，这轮也参考了 Pinia 官方关于核心概念、Vuex 迁移和 Nuxt 集成的文档，把案例往现代 Vue / Nuxt 实战方向对齐。

本轮自测怎么做

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

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

本轮结果

M5-3 完成后，当前方法库已经不再只是按页面和组件类型组织，而是开始覆盖一条更底层的架构主线：状态中心设计。

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

• Vuex 模块拆分
• Pinia store 设计
• Nuxt store 组织方式
• UI store / session store / domain store 分层

都已经有了稳定挂载点。