多终端系统数据同步原理，核心解决两件事（手机APP、电脑端、小程序共用一套数据）的同步原理，核心解决两件事：变更怎么高效传到另一端（增量同步），两端同时改同一条数据怎么办（冲突处理）。状态追踪是保证同步不丢、不重的基础设施。下面拆解这三块的实现原理。

增量同步原理

变更日志机制

全量同步太浪费——每次打开APP都把所有数据拉一遍，慢且费流量。实际做法是增量同步：服务端记录每条数据的变更时间戳或版本号，客户端上次同步后，只拉比这个时间戳新的数据。

实现上，每张表加两个字段：update_time（最后修改时间）和version（版本号，每次修改+1）。客户端请求时带上"我最后同步到几点"，服务端返回比这个时间新的数据。西陵区企业的CRM、进销存、审批APP都是这个原理。

删除操作也要同步。不能真删数据库记录，要做软删除：标记is_deleted=true，同步时把"已删除"状态传给客户端，客户端本地也标记删除。真删了客户端不知道，下次同步又把老数据传上来。

版本号与时间戳的选择

时间戳简单，但跨时区、服务器时钟不准时会出问题。更稳妥的是版本号：每条数据有一个自增版本号，每次修改+1。客户端记录自己见过的最大版本号，下次同步从这个位置继续。

版本号还有个好处：能检测"我这边改的时候，服务端已经被别人改过了"。提交时带上本地版本号，服务端发现版本号不匹配，就说明有冲突，不能直接覆盖。

同步还要考虑数据量。几万条数据的小表全量同步没问题，几百万条的大表必须增量。大表全量同步一次要几小时，用户体验很差。

多终端还要处理哪台设备是主的问题。一般以最后操作为准，但有些场景要指定主端：比如后台管理端是主，移动端是从，后台改了数据强制覆盖移动端。这个规则要业务定义清楚。

冲突处理策略

最后写入胜出

两端同时改同一条数据，最常见的策略是最后写入胜出（LWW）：后提交的修改覆盖先提交的。服务端用版本号判断：A提交时版本是5，B提交时版本也是5，服务端发现冲突，取后到的B的版本，返回给A"你的修改被覆盖了"。

这个策略简单，但可能丢数据。A改了价格、B改了库存，两个修改其实不冲突（改的不同字段），但LWW会把整个记录覆盖掉。西陵区企业的库存、订单这种多字段数据，要用更细的策略。

字段级合并

字段级合并是只看冲突字段：A改了价格、B改了库存，两个字段都保留；A和B都改了价格，才用LWW。实现上，每次修改记录"改了哪些字段"，合并时按字段比对。

更复杂的业务（比如审批流）不适合自动合并，要返回给用户"这条数据在另一端也改了，你看看怎么合并"，人工决策。

同步状态追踪

同步进度记录

客户端本地记录：上次同步成功的时间、拉到的最大版本号、哪些数据正在上传没成功。打开APP时先读本地缓存展示，后台同时同步，同步完刷新。

弱网环境（地下车库、电梯）上传会失败，客户端要把未上传的修改存本地队列，网络恢复后自动补传。西陵区企业的外勤人员在仓库扫码、地下车库录数据，全靠这个机制。

失败重试与告警

同步性能也要优化。数据量大时，同步一次要几分钟，用户体验差。优化方法：分页拉取、压缩传输、只同步变更字段。这些优化做了，同步时间能缩短到几秒。

同步体验的关键是用户无感知。用户在手机上改了数据，打开电脑自动就有了，不需要手动刷新。做到这种体验，背后是增量同步、冲突处理、状态追踪一整套机制。

同步冲突的兜底策略：实在处理不了的冲突，推送给用户人工决定。不要系统自动合并出错数据，用户自己选哪个版本是对的。

同步性能还要优化索引。数据库表数据量大了，按版本号查询会慢。加索引、分表分区，同步速度才能上去。

同步还要做用户提示。同步中显示个转圈图标，同步完提示已更新，失败提示重试。用户体验靠细节，不只是技术。

同步还要做版本兼容。APP升级后，老版本客户端还要同步。新版本改了数据结构，老版本怎么处理？要向前兼容，不能一升级老版本就崩。

同步还要做性能测试。一万条数据同步要多久？十万条呢？数据量大了同步慢，用户体验差。提前压测，发现瓶颈提前优化。

同步体验做好了，用户感觉不到它的存在。打开APP数据就是最新的，这就是最好的同步。

多终端同步的细节决定用户体验。做不好，用户天天报数据不一致；做好了，用户根本感觉不到同步的存在。

同步失败不能无限重试。设置重试次数（比如3次），超过3次标记为"同步异常"，提示用户"这条数据没传上去，请检查网络后重试"。服务端也要监控同步失败率，某客户端一直同步不上，可能是数据坏了或客户端版本太老。