M5详细设计：SSR 数据流与水合边界

这份设计文档说明 M5 第一轮案例为什么选择 SSR / hydration，以及它将如何接入现有文档体系。

设计目标

把 SSR 示例里最关键的数据流问题，抽象成与现有案例兼容的一篇方法型案例。

为什么优先选 SSR

在当前里程碑规划里，M5 的候选方向包括：

• 更多 Nuxt / Vue 3 场景
• 状态管理场景
• SSR / hydration 场景
• 动画与复杂交互场景

其中 SSR 最适合作为第一条扩展线，因为它和前面 6 篇案例形成互补：

• 前 6 篇更偏客户端状态与组件边界
• SSR 案例补的是“运行时边界”和“同构数据流”

这会让方法库从客户端重构，扩展到服务端与客户端协作重构。

本轮案例的复杂度中心

本轮不以某个单一组件为核心，而是以整条数据流为核心。

复杂度中心包括：

• 请求级应用创建
• 路由匹配后的组件级预取
• 初始状态序列化
• 客户端接管后的增量预取
• 页面组件的数据依赖声明

与现有框架的映射关系

本轮案例接入现有统一框架时，重点映射到下面几个步骤：

• 第三步：先稳定模型，再拆组件
• 第四步：判断状态应该放在页面、组件还是 composable
• 第六步：显式数据流优先，隐式通信后退
• 第七步：把副作用和派生状态分开

也就是说，这篇案例并不是脱离原框架的补充，而是对“跨运行时数据流”这一块的延展。

交付物设计

本轮预期交付物包括：

• 新案例：../SSR数据预取与水合重构.md
• 新任务拆解：04-M5任务拆解-SSR与水合场景.md
• 新详细设计：05-M5详细设计-SSR数据流与水合边界.md
• 新开发记录：06-开发记录-SSR与水合文档化重构.md

设计约束

本轮依然遵循此前的项目约束：

• 不直接修改独立 demo 子项目源码
• 只把核心逻辑和方法提炼进文档
• 每次新增案例都要同步更新入口与方法层

接入后的预期效果

完成后，当前方法库将具备：

• 客户端页面重构案例
• 基础组件重构案例
• SSR / hydration 数据流重构案例

这样后续如果继续扩展 Nuxt、SSR 或数据预取类主题，就会有一个稳定挂载点。