M5-3详细设计：状态边界与 Pinia 迁移

这份设计文档说明 M5-3 为什么选择状态管理场景，以及它将如何接入现有方法库。

设计目标

把状态管理从“API 选型问题”还原成“状态边界设计问题”，并用一篇案例把 Vuex 与 Pinia 的结构差异、迁移顺序和现代组织方式说清楚。

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

在当前方法库里，已经补齐了：

• 客户端页面重构
• 基础组件重构
• SSR / hydration 运行时边界
• Nuxt 页面数据获取与渲染边界

下一步最自然补的，就是状态中心本身。因为状态管理几乎会影响前面所有场景：

• 页面型案例会受到全局状态边界影响
• SSR / Nuxt 场景会受到状态恢复和共享影响
• 基础组件场景会受到上下文与全局状态关系影响

所以状态管理是一个非常适合作为 M5-3 的横向扩展线。

本轮案例的复杂度中心

本轮复杂度中心主要有四个：

• 全局状态的真实边界
• store 的业务域划分
• action / 副作用 / 派生状态的分层
• 从 Vuex 向 Pinia 迁移的渐进顺序

与现有框架的映射关系

本轮将重点强化统一框架中的这些步骤：

• 第二步：找到真正的复杂度中心
• 第四步：判断状态应该放在页面、组件还是 composable
• 第七步：把副作用和派生状态分开
• 第八步：先收口协议，再谈扩展能力

本轮交付物

本轮预期交付物包括：

• 新案例：../Vuex状态中心与Pinia迁移重构.md
• 新任务拆解：10-M5-3任务拆解-状态管理场景.md
• 新详细设计：11-M5-3详细设计-状态边界与Pinia迁移.md
• 新开发记录：12-开发记录-状态管理与Pinia迁移重构.md

设计约束

本轮继续遵循当前项目约束：

• 不直接修改独立 demo 源码
• 只提炼核心逻辑与方法进入文档
• 每轮新增案例都要同步更新入口、导航和总框架

完成后的预期效果

完成后，当前方法库将会同时覆盖：

• 页面型重构
• 基础组件型重构
• 运行时边界型重构
• 框架场景型重构
• 状态管理型重构

这会让整套方法库从“若干案例集合”，进一步长成更完整的 Vue / Nuxt 架构重构地图。