网络恢复后自动同步采用“监听→队列→执行→更新”四步闭环：监听 navigator.online 与 online 事件，结合探针验证服务可达；操作入 syncqueue 队列并按时间排序；web worker 或 requestidlecallback 异步逐条上传，幂等校验与冲突处理；同步成功后更新 issynced 字段、广播事件并跨页刷新。
网络恢复后自动同步，核心是“监听→队列→执行→更新”四步闭环。不依赖响应式系统做同步，而是让它专注渲染；同步本身应独立运行、失败可重试、成功再通知 UI 更新。
监听网络状态变化
用 navigator.onLine 搭配 online 事件监听网络恢复，比轮询更轻量高效。注意它只反映浏览器是否认为联网，不能代替真实请求测试，所以同步前建议加一次快速探针（如 HEAD 请求）确认服务可达。
- 注册监听：在应用初始化时绑定
window.addEventListener('online', handleSync) - 避免重复触发：事件可能多次触发，可用节流或标记位控制只启动一次同步任务
- Service Worker 场景下，还可监听
sync事件（需先调用sync.register('tag')），更适合后台静默执行
维护本地待同步队列
所有离线期间的写操作（增删改）都生成结构化记录，存入专用对象仓库（如 syncQueue），每条含操作类型、目标表名、原始数据、时间戳、唯一 clientOpId。
- clientOpId 推荐用 UUID + 时间戳组合，确保跨设备/多标签页不重复
- 写入 IndexedDB 后立即触发 UI 更新，但不发网络请求——UI 和本地数据保持一致
- 队列支持按 updatedAt 升序排序，保证变更按发生顺序提交，降低冲突概率
异步执行同步任务
同步过程必须脱离主线程，避免阻塞 UI。推荐使用 Web Worker 或 requestIdleCallback 执行批量上传，每条请求独立处理、失败单独标记。
- 逐条发送：对每条队列项发起 fetch，携带 clientOpId 和 contentHash 做幂等校验
- 服务端返回 409 时，把远程数据存入临时仓，触发前端合并提示（不自动覆盖）
- 成功后从队列中删除该条；失败则写入 syncError 字段，并保留原记录供用户手动重试
同步完成后的状态更新
同步不是为了“推数据”，而是为了“对齐状态”。成功后需清理本地元数据，并广播变更，让各模块响应。
- 更新对应数据表中的
isSynced: true字段，或删除已同步的草稿 - 通过自定义事件（如
dispatchEvent(new CustomEvent('data-synced'))）通知所有监听 Hook 重新读取 - 多标签页场景下，配合 localStorage 写入时间戳信号，其他页面监听
storage事件触发刷新
