indexeddb 本身不支持自动双向同步，需自行实现变更追踪、冲突解决和增量同步机制：本地用 changes 仓库记录所有操作日志，云端通过 lastsynctime 拉取增量并接收 pending 变更，结合 version 或时间戳检测冲突，网络恢复后按退避策略自动重试。
IndexedDB 本身不提供自动同步能力，双向同步需要你自行设计一套“变更追踪 + 冲突解决 + 增量同步”的机制。核心不是 IndexedDB 能不能同步，而是你怎么用它来支撑离线优先、最终一致的同步流程。
本地变更记录：用 IndexedDB 存储操作日志
每次增删改操作，不要只写业务数据，还要在专用的 changes 对象仓库中追加一条变更记录（含操作类型、表名、主键、新旧值、时间戳、本地 ID）。这样即使网络中断，也能知道哪些修改还没上云。
- 建议字段包括：
id（自增或 UUID）、operation（"add"/"update"/"delete"）、tableName、recordId、data（变更后快照或 diff）、timestamp、status（"pending"/"synced"/"failed"） - 更新时优先更新
changes仓库，再更新业务数据仓库——保证日志不丢 - 删除操作也要记日志（哪怕只是记录
recordId和delete类型），否则云端无法感知
云端同步策略：拉取增量 + 提交本地变更
同步分两步走：先从服务端拉取自上次同步以来的新数据（带服务器时间戳或版本号），再把本地 pending 的变更批量提交过去。
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 客户端保存一个
lastSyncTime（存在 IndexedDB 或 localStorage），请求时带上它，服务端返回该时间之后的所有变更 - 提交本地变更时，用 POST 发送
changes中 status="pending" 的记录；成功后批量更新这些记录的 status 为 "synced" - 推荐使用事务性接口（如 RESTful 的
/sync端点），服务端原子处理一批变更，避免部分失败导致状态不一致
冲突检测与解决：靠时间戳或版本号判断谁“更晚”
当本地和云端都改了同一条记录，必须决定以谁为准。常见做法是“最后写入者胜”（LWW），但需确保时钟基本一致；更稳妥的是用向量时钟或业务规则（如“用户编辑优先”）。
- 每条业务数据加一个
version字段（数字递增）或updatedAt（ISO 时间字符串），服务端和客户端都维护它 - 同步拉取时，如果发现某条记录的云端
version> 本地version，说明云端有更新 → 覆盖本地 - 提交变更时，服务端检查当前云端
version是否等于客户端提交时携带的旧version；不等则拒绝并返回当前值，由前端提示用户合并
网络恢复后的自动同步与错误重试
监听 online 事件触发同步，但别一上线就狂发请求。加入节流、失败退避、手动重试入口更友好。
- 用
navigator.onLine判断基础连通性，再用 fetch 测试真实 API 可达性（因为 onLine 可能误报） - 对失败的变更记录标记
retryCount，每次重试间隔指数增长（如 1s → 3s → 9s） - 提供 UI 显示“待同步项数量”和“同步失败项”，允许用户手动重试或放弃某些变更
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
