异步任务是实现离线数据同步的关键机制——它让应用在无网络时照常响应用户操作，等联网后再悄悄完成同步，全程不卡界面、不中断体验。
本地变更先存后发
用户在断网状态下新增、修改或删除数据，这些操作不能直接发请求，而是立即写入本地数据库（如 IndexedDB 或 SQLite），同时记录操作类型、时间戳和唯一 ID。每条记录还应标记为“未同步”状态，便于后续识别和重试。
- 例如：用户离线编辑一条笔记，系统将其保存到 IndexedDB 的 pending_notes 表，并设置 sync_status: 'pending'
- 避免直接覆盖原始数据表，单独维护一个待同步队列更利于追踪和回滚
网络恢复触发后台同步
监听网络状态变化（如使用 Navigator.onLine 配合 Service Worker 的 fetch 事件，或 Android 的 ConnectivityManager），一旦检测到有效连接，就自动启动同步任务。
- 同步过程必须异步执行，推荐用 Promise 或 Observable 封装 HTTP 请求，防止阻塞主线程
- 优先按时间顺序或依赖关系处理待同步项，确保数据逻辑一致（比如先同步父项再同步子项）
- 失败时不丢弃任务，记录错误并设置重试次数上限，支持指数退避重试
同步结果要双向更新
一次同步不是单向上传，而应包含“上传本地变更”和“拉取远程更新”两个方向，且需保证最终一致性。
- 上传成功后，将对应记录的 sync_status 改为 'synced'，并清理临时字段
- 下载远程新数据时，需比对版本号或最后更新时间，避免用旧数据覆盖新数据
- UI 层通过响应式状态（如 RxJS Subject、LiveData、Signals）自动刷新，用户无感知但数据已最新
冲突时要有明确策略
当本地修改与服务器最新版本发生冲突，不能简单报错或丢弃，而应按预设规则处理。
- 服务器优先：适用于强中心化场景（如订单状态），以服务端为准，本地变更视为过期
- 客户端优先：适合高离线编辑频率场景（如笔记、草稿），保留用户本地操作，同步后由服务端合并或打标提醒
- 带时间戳自动合并：对字段级差异做浅合并（如仅更新非空字段），或生成冲突记录供用户后续确认
