鸿蒙云同步待办清单实战：端云一体架构下如何设计离线优先的数据同步

待办清单是最常见的练手应用，但加上"云同步"三个字后，难度立刻上了一个台阶：本地离线可用、多端数据一致、冲突如何解决，每一项都要认真设计。参考鸿蒙开发实践中心的"云同步待办清单"案例走了一遍流程，把关键设计决策整理成文。

一、离线优先是基调

同步类应用最容易犯的错误是把"在线"当默认状态。实际使用中，电梯、地铁、弱网环境随处可见。正确的做法是：所有读写操作先落本地数据库，同步作为后台任务异步执行。用户添加一条待办，界面立刻响应，网络请求成功与否不影响操作完成。

本地存储用关系型数据库即可，待办事项建一张主表，字段包括唯一标识、标题、描述、截止时间、完成状态、更新时间戳和删除标记。注意更新时间戳要单调递增，它是后续同步与冲突判定的依据。

二、唯一标识与增量同步

每条待办在创建时就生成全局唯一 ID，而不是等服务端返回。这样离线创建的数据可以直接同步上传，不需要二次映射。

同步协议采用增量模式：客户端记录上次同步时间点，每次只上传该时间点之后变更的记录，也只下载服务端新增的变更。全量同步只在首次登录或数据修复时使用。待办数据量小，但增量同步的习惯值得保持，换成图片、日志类数据时就是刚需了。

三、冲突处理：以时间戳为准，删除用软删除

两端同时修改同一条待办时，简单可靠的策略是"最后写入者优先"：比较记录的更新时间戳，保留较新版本。对个人待办这种低并发场景足够用，不必引入复杂的向量时钟。

删除必须用软删除：本地删除只是打上删除标记，同步时把这个标记上传，服务端据此删除，其他设备同步时收到删除事件。如果直接物理删除，其他设备无法感知，数据会"复活"。

四、登录态与多设备

云侧按用户维度隔离数据，端侧只持有登录令牌，不保存账号密码。多设备登录同一账号时，每台设备维护各自的同步位点，互不干扰。退出登录时清空本地数据与令牌，避免换账号后看到上一任的数据残留。

五、同步触发时机

三类触发点比较实用：应用回到前台时、本地数据变更后延迟数秒批量同步、以及固定周期兜底同步。把频繁的零散操作合并成批量请求，既省流量也降低服务端压力。同步失败要有退避重试，网络恢复后自动补传。

小结

待办清单麻雀虽小，把离线优先、增量同步、软删除、冲突策略这几件事做对，就是一个完整的端云一体样板间。这套设计可以平移到笔记、收藏、习惯打卡等任何"个人数据多端同步"的场景。鸿蒙实践中心这个案例的价值，在于把这些决策都用代码落地了，适合对照着敲一遍。