Zustand 状态管理架构
Zustand State Architecture
大型 Electron 应用的 Zustand 多 Store 架构、持久化适配与项目切换协调
子问题
1.多 Store 职责划分
2.自定义 fileStorage 持久化适配器
3.partialize 选择性序列化
4.多 Store 协调切换与 rehydrate
5.三层 Storage 适配器叠加与职责分离
6.setItem 竞态条件下的跨项目数据覆盖防护
7.base64 图片数据的序列化膨胀控制
8.localStorage/IndexedDB 到文件系统的自动迁移
9.9 版本链式 schema 迁移
各项目的解法1 solutions
Signals
横向对比
| 维度 | moyin-creator |
|---|---|
| Store 数量与粒度 | 17 个独立 store，按业务域拆分（导演/剧本/角色/素材等） |
| 持久化策略 | 三层 Storage 适配器：fileStorage → ProjectScoped → SplitStorage |
| 项目隔离机制 | _p/{projectId}/{storeName} 文件路径物理隔离 |
| 版本迁移 | api-config-store 实现 v0→v9 链式 migrate，每版本独立处理 |
| 序列化优化 | partialize + stripBase64 过滤 data: URL，避免 100MB+ JSON |
| 多 Store 协调 | project-switcher 5 步协议：路由→rehydrate×7→同步 ID |
| 跨项目共享 | createSplitStorage 拆分项目数据与共享数据到不同文件 |
| 竞态防护 | setItem 从数据提取 projectId，不依赖全局状态 |
最佳实践
1.persist 中间件+自定义 storage 适配器
2.onRehydrateStorage 恢复派生状态
3.project-switcher 统一协调切换顺序
4.setItem 从序列化数据提取 projectId 而非依赖全局状态防竞态
5.partialize + stripBase64 过滤 data: URL 控制序列化体积
6.switchProject 先路由后 rehydrate 再同步 ID 的有序协议
7.hasRichData 启发式判断实现跨存储源自动迁移