indexeddb 数据导出与导入需同步保存 schema（store 名称、keypath、索引等）与数据，分页读取防内存溢出，版本匹配校验、事务写入、断点续传及导入后抽检验证确保一致性。
IndexedDB 数据导出与导入的核心在于把数据库结构和数据完整序列化为可存储、可传输的格式（如 JSON），再反向重建数据库。关键不是简单 dump 所有对象，而是兼顾版本兼容、索引完整性、键路径一致性以及大体积数据的流式处理能力。
导出：提取数据库快照并结构化保存
导出需遍历所有 objectStore，读取每条记录，并保留 schema 信息（如 store 名称、keyPath、index 定义）。不能只导出数据，否则导入时无法重建索引或判断主键类型。
- 打开数据库时使用 readonly 模式，避免阻塞写操作
- 对每个 objectStore 调用 openCursor() 分页读取（如每次 1000 条），防止内存溢出
- 收集每张表的 store.name、store.keyPath、store.autoIncrement 和所有 index 的 name、keyPath、unique 属性
- 将数据与 schema 合并为一个标准结构：{ version: 1, stores: [ { name: "users", keyPath: "id", autoIncrement: false, indexes: [...], data: [...] } ] }
导入：按版本重建库结构并批量写入
导入前必须检查目标数据库版本是否匹配或可升级。若 schema 不一致（比如新增了 index 或修改了 keyPath），应拒绝导入或提示用户手动迁移，而非强行覆盖。
- 用 indexedDB.open(dbName, newVersion) 触发 upgradeNeeded，根据导出的 schema 动态创建/更新 objectStore 和 index
- 对每个 store 使用 transaction.objectStore(name).add() 或 put() 写入；禁用 autoIncrement 的 store 必须显式提供 key
- 启用事务的 oncomplete 钩子控制流程，失败时回滚并返回具体错误（如 key 冲突、类型不匹配）
- 支持断点续传：记录已成功写入的 record ID 或游标位置，异常中断后可从断点恢复
文件交互：浏览器端生成与读取备份文件
导出结果通常封装为 .json 文件供用户下载；导入则依赖 读取用户选择的备份文件。全程不经过服务器，纯前端完成。
- 导出时用 Blob + URL.createObjectURL() 创建下载链接，设置 filename 为 dbName_YYYYMMDD_HHMMSS.json
- 导入时用 FileReader.readAsText() 解析 JSON，校验顶层字段（version、stores）、store 数量及必填属性是否存在
- 对超大文件（>50MB）做进度提示：监听 FileReader 的 onprogress 事件，估算解析耗时
- 禁止直接 JSON.parse() 整体加载——改用 stream-json 类库或分块解析，降低内存压力
容错与验证：确保备份可用性
一次成功的备份不是“能导出+能导入”，而是导入后数据可查、索引可查、业务逻辑无异常。因此必须加入轻量级验证环节。
- 导出完成后，自动计算所有 records 的 JSON.stringify().length 并记录总条数，写入 metadata 字段
- 导入后执行抽检：对每个 store 随机取 3 条记录，比对原始备份中的对应字段值
- 运行 count() 校验每张表记录数是否一致；对含 index 的 store，用 index.get() 验证索引查询路径是否有效
- 将验证结果（通过/失败项、差异详情）以 console.warn 或 UI 提示方式暴露给开发者或高级用户
