离线同步是怎么一回事？
你有没有遇到过这种情况：地铁进隧道，手机断了网，可你还在记账、写笔记、填表单。等出了隧道连上Wi-Fi，发现数据居然自动上传，和电脑上的内容一模一样。这背后靠的就是“离线同步”。
简单说，离线同步就是让你在没网络的时候也能操作数据，等网络恢复后，设备自动把改动补传上去，和其他设备保持一致。
核心流程拆解
整个过程不像想象中复杂，画个流程图就清楚了：
用户操作 → 本地存储变更 → 标记待同步 → 网络检测 → 差异比对 → 数据上传 → 远程确认 → 本地标记完成每一步都在后台悄悄进行。比如你在通勤路上删了一条备忘录，系统不会立刻去服务器删，而是先在本地删掉，再给这条记录打个“已删除”的标签，存进一个“待处理队列”。
冲突怎么处理？
两个人同时改同一个文件怎么办？比如你在家改了文档标题为“项目终稿”，同事在公司改成了“最终版提交”。网络恢复后，系统发现版本不一致，就会触发冲突解决机制。
常见做法是保留两个版本，加上时间戳和设备名，比如“项目终稿（你的手机）”和“最终版提交（同事电脑）”，由人工决定留哪个。有些系统会尝试自动合并，比如文本类内容按段落对比，保留双方修改。
本地数据库的角色
离线能用，全靠本地有套小型数据库，像 SQLite、Realm 或 IndexedDB。每次操作都写入本地，响应快，不依赖网络。比如记账App在断网时依然能添加支出，就是因为数据先存到了本地库。
代码结构大致长这样：
if (navigator.onLine) {
syncData();
} else {
saveToLocalDB(data);
queueForSync(data);
}这段逻辑判断是否有网，有网就同步，没网就存本地并加入同步队列。
同步时机的讲究
不是一有网就狂传。系统通常会等网络稳定、设备充电、空闲时才开始同步，避免影响用户操作。比如晚上手机插着电连Wi-Fi，它可能就在后台默默上传白天积累的更改。
有些App还会做增量同步——只传变化的部分，而不是整个文件。改了10个字的文档，没必要重传1万字。
实际场景中的表现
拿笔记类App来说，你在咖啡馆写了一段灵感，突然断网，但输入框依然响应。你合上笔记本，换地方继续写。等回到家连上Wi-Fi，几分钟后所有设备都更新了最新内容，就像从没断过网一样。
这种体验的背后，是一整套状态管理、数据校验和重试机制在支撑。哪怕同步失败，系统也会定期重试，直到成功为止。
离线同步不是魔法，是设计精密的流程在默默工作。下次你在电梯里发完一条消息，出来发现已送达，就知道那几秒里发生了多少事。