端云一体应用的数据同步设计：本地优先与冲突处理

为什么端云一体绕不开同步问题

移动应用的端云一体架构，本质上是在解决一个矛盾：用户希望操作立即响应，而数据又必须可靠地落到云端。直接每次都请求服务端，弱网下体验会很差；只写本地，又会带来多端数据不一致。真正可用的方案，几乎都会走向「本地优先 + 增量同步」。

本地优先：先写本地，再择机上云

本地优先的核心是把本地数据库当作唯一的数据入口。用户的每一次增删改，先写入本地，界面立即更新，然后由同步层在合适的时机推送到服务端。

// 写入时同时打上同步状态
await localDb.insert({
  id: recordId,
  payload: data,
  syncState: "pending",   // pending / synced / failed
  updatedAt: Date.now(),
  version: 1
})

这样做的好处是操作与网络彻底解耦。代价是需要维护一份待同步队列，以及在多端同时修改时的冲突判断。

增量同步：只传变化的部分

全量同步在数据量上来后会很快变得不可接受。更常见的做法是给每条记录维护一个版本号或更新时间戳，同步时只请求「比本地最新版本更新」的记录。

GET /changes?since=1699999999&limit=200

服务端返回增量列表与下一个游标，客户端按游标继续拉取，直到没有更多变化。拉取和推送最好分开处理：拉取解决「别人改了我不知道」，推送解决「我改了别人不知道」。

冲突处理：先定规则，再写代码

多端同时修改同一条记录时必然产生冲突。关键不是避免冲突，而是提前约定解决规则。常见的三种策略：

1. 最后写入优先：按更新时间戳取最新。实现简单，但会静默丢失另一端的修改。 2. 字段级合并：不同字段各自保留最新值，只有同一字段冲突才需要人工介入。 3. 版本号校验：每次提交带版本号，服务端版本不匹配则拒绝，由客户端拉取最新后重新合并。

对记账、待办这类应用，字段级合并往往最贴近用户预期；对金额、库存等强一致场景，则应使用版本号校验并明确提示用户。

弱网与失败重试

同步失败不能简单丢弃。待同步队列应当持久化，并在网络恢复、应用启动、页面可见等时机重试。重试要有退避策略，避免弱网下频繁请求把电量和流量耗光。

另一个容易被忽略的点是幂等。同一条记录可能因为超时被重复推送，服务端需要用客户端生成的唯一 ID 做幂等处理，否则会出现重复数据。

安全边界

临时凭据、访问令牌不应硬编码在客户端。端云一体的应用更适合使用短时效凭据，并配合服务端做权限校验——客户端只能声明「我想改哪条」，能不能改由服务端判断。

小结

端云一体的同步设计，可以归纳成四件事：本地先写保证体验，增量传输控制成本，明确的冲突规则保证结果可预期，持久化重试与幂等保证可靠性。把这四点想清楚，比选择哪套同步框架更重要。