pinia 可通过手动集成 indexeddb 实现大型离线数据缓存，利用其异步、大容量、支持索引与事务的特性替代 localstorage；需封装 idb 工具类、在 store 初始化和变更时同步读写、处理版本迁移与跨标签页同步等细节。
Pinia 本身不直接支持 IndexedDB，但可以通过自定义持久化逻辑，把状态写入或读取 IndexedDB，从而支撑大型离线数据缓存。关键不是“替换 Pinia”，而是让 Pinia 的 store 在初始化和更新时，与 IndexedDB 同步——尤其适合含大量结构化数据、二进制资源（如图片缩略图）、或需复杂查询的场景。
为什么不用 localStorage？
localStorage 容量小（通常 5MB）、只能存字符串、同步阻塞主线程。当你的应用要缓存几百条带附件的笔记、完整产品目录或离线地图瓦片时，它会迅速卡顿甚至失败。IndexedDB 提供异步、大容量（可达硬盘空间的 50%+）、支持索引与事务的能力，是真正意义上的浏览器端数据库。
Pinia + IndexedDB 的协作方式
核心思路：不依赖 pinia-plugin-persistedstate 的默认 localStorage 行为，而是手动接管 store 的持久化生命周期，在 store 创建时从 IndexedDB 加载，在状态变更后写入。
- 封装一个 IndexedDB 工具类：用 IDBWrapper 或原生 IDB API 封装 open、get、put、delete、index 查询等方法，统一管理数据库版本、对象存储（objectStore）和索引（如按 userId、updatedAt 排序）
- 在 store 中手动集成读写逻辑：在 defineStore 的 setup 或 state 初始化阶段调用 IDB 读取；通过 actions 或 $subscribe 监听变更，触发 IDB 写入
- 避免直接序列化整个 state：IndexedDB 原生支持存储 JS 对象（包括 Date、Array、嵌套对象），无需 JSON.stringify；对 Map/Set 等特殊结构，可在写入前转为数组，在读取后重建
- 分块处理大数据：例如用户消息列表超千条，可按时间分页存为多个 record，配合 index（"timestamp"）实现快速拉取最近 50 条
典型代码结构示意
以缓存用户笔记为例：
- 创建 notesDB 数据库，包含 notes 对象存储，主键为 id，建立 title、updatedAt 索引
- store 定义中，state 初始化时 await idb.getNotes() 获取全部笔记（或增量同步标记）
- 新增笔记 action 中，先调用 idb.putNote(note)，再更新 this.notes 数组；失败时抛出错误并保留本地临时状态
- 搭配 service worker 实现后台静默同步：网络恢复后自动将本地未提交的变更 POST 到服务端，并更新 IndexedDB 标记为已同步
注意事项与优化点
实际落地时需关注几个关键细节：
- 版本迁移：IndexedDB 升级 schema 需监听 onupgradeneeded，例如新增字段时迁移旧数据，否则打开失败
- 错误降级：IDB 操作可能失败（如磁盘满、权限拒绝），应 fallback 到内存缓存，并提示用户“离线内容暂未保存”
- 跨 tab 同步：IndexedDB 不自动广播变更，需结合 BroadcastChannel 或 storage 事件通知其他标签页 reload 数据
- 清理策略：设置 TTL（如 7 天未访问的缓存自动删除），防止无限膨胀；可用 IDBKeyRange.bound 配合 cursor 清理过期记录
不复杂但容易忽略：IndexedDB 是异步且事务性的，别在 $subscribe 回调里直接 await IDB 操作却不做 loading 状态隔离，否则 UI 可能卡顿或出现竞态。把写操作包裹在独立事务中，并用 pending 标志控制重复提交即可。
