Pinia State 初始化恢复需在store创建前读取localStorage并覆盖默认state，通过插件机制结合$subscribe自动持久化、storage事件同步多标签页状态，并提供flush/reload/migrate等手动控制能力。
Pinia State 结合本地缓存实现初始化恢复，关键是在 store 创建完成前、响应式代理建立之前，把 localStorage 中的数据读出来并覆盖默认 state。这个过程不能靠组件挂载后手动赋值，否则会错过首次渲染的正确状态，也不该依赖 watch + setItem 这类手动同步方式——既容易漏掉、又可能触发多余更新。
初始化阶段主动注入缓存数据
Pinia 插件机制允许你在每个 store 实例创建时介入。利用 store.$id 构造唯一 key（如 localStorage.getItem(`pinia/${store.$id}`)），在插件函数中尽早读取并赋值：
- 必须在
store.$onAction或store.$subscribe之前执行，确保不被后续响应式逻辑干扰 - 推荐直接赋值：
store.$state = JSON.parse(stored) || store.$state，避免用Object.assign或逐字段设置，防止触发不必要的 getter/setter - 若 state 含不可序列化内容（如函数、Date 对象），需在写入前清洗或使用自定义序列化逻辑
变更后自动写回本地缓存
仅恢复还不够，用户操作后的最新状态必须及时落盘，否则刷新即丢失。Pinia 提供 store.$subscribe，它在 commit 完成后触发，适合做持久化写入：
- 启用
{ detached: true }选项，让监听脱离组件生命周期，保证后台 tab 或非活跃组件也能生效 - 建议节流处理高频变更（如输入框实时搜索），可结合防抖或只监听特定字段变化
- 写入前做简单校验：跳过 undefined、NaN、函数等非法值，避免污染缓存
多标签页状态同步不能只靠单次恢复
单纯初始化读一次 localStorage，无法解决用户在另一个 tab 修改后当前 tab 状态滞后的问题。需要监听浏览器的 storage 事件：
- 在插件中为 window 添加
storage监听器，当同域下其他 tab 触发 localStorage 变更时，比对 key 是否匹配当前 store，匹配则重新读取并合并 - 注意避免循环写入：读取后更新 state 会再次触发 $subscribe，需加标记位或版本号控制
- Electron 环境下 storage 事件不触发，应改用 IPC 或共享内存方案替代
提供手动控制能力增强可靠性
自动流程难免遇到异常场景（如缓存损坏、格式迁移、用户主动清除），插件应暴露基础控制接口：
-
store.$persist.flush()：强制将当前 state 写入缓存 -
store.$persist.reload()：忽略当前内存 state，重新从缓存加载 -
store.$persist.migrate()：支持旧版数据结构转换，配合beforeHydrate钩子使用 - 所有操作都应返回 Promise，方便上层做 loading 或错误提示
