IndexedDB 增量备份基于应用层数据变更感知与结构化快照，通过 updatedAt 时间戳、全局版本号或操作日志队列识别差异；备份文件为含元信息、变更数据及校验字段的 JSON；恢复时按 add/put/delete 类型精准执行并事务包裹；常结合 localStorage 存储锚点信息与临时备份。
IndexedDB 的增量备份不是照搬 MySQL 那套日志+binlog 的机制，而是基于应用层的数据变更感知与结构化快照来实现的。它不依赖数据库引擎内置的事务日志，而是由前端代码主动识别“哪些记录新增、修改或删除”，再只导出这部分差异数据。
增量备份的核心判断依据
关键不在时间戳或序列号，而在业务语义层面的数据状态标记。常见做法包括：
- 为每条记录添加
updatedAt字段，并在每次写入时自动更新；备份时查询所有updatedAt > 上次备份时间戳的记录 - 维护一个全局版本号（如
dbVersion或syncSeq），每次变更后递增；备份只取大于上一次保存版本号的记录 - 对高频操作场景（如打字练习、聊天消息），采用“操作日志队列”模式：将
add/update/delete操作暂存为 JSON 数组，批量提交后再触发增量导出
备份内容组织方式
增量备份文件通常是一个轻量级 JSON 对象，结构清晰，便于传输和校验：
- 元信息区：含备份时间、起始版本号、目标对象仓库名（objectStoreName）、总变更条数
-
变更数据区：按操作类型分组，例如：
{"added": [...], "updated": [...], "deleted": ["id1", "id2"]} -
可选校验字段：如
checksum（对变更数据做 SHA-256）或prevHash（链接前一次备份哈希），用于构建备份链完整性
恢复逻辑的关键细节
恢复不是简单覆盖，而是按操作类型精准执行，确保不破坏已有数据一致性：
-
新增记录：直接调用
add()，若主键冲突则跳过或抛错（取决于业务容忍度） -
更新记录：使用
put()替换原值；注意检查updatedAt是否晚于本地现有值，避免旧数据覆盖新数据 -
删除记录：调用
delete()；若 ID 不存在，静默忽略（幂等设计） - 整个恢复过程应包裹在单个
transaction中，并监听oncomplete和onerror，失败时可回滚或记录断点
与 localStorage 协同的实用策略
浏览器环境受限，不能像服务端那样持久挂载磁盘，所以常借助 localStorage 做“临时备份锚点”：
- 每次成功完成一次增量备份后，把本次的
lastBackupTime或lastVersion写入 localStorage，作为下一次增量的起点 - 备份文件本身也可存为字符串塞进 localStorage（注意 5–10MB 限制），同时提供“导出为 .json 文件”按钮供用户手动保存
- 应用启动时检查 localStorage 中是否存在未上传的增量包，有则自动触发同步上传逻辑（如发往用户专属云存储）
