手工处理冲突交互上可能比较麻烦。最理想的算法应该是避免产生冲突（比如 CRDT），但是实现上有难度、网络带宽成本较高，性能也不大行。

目前同步算法的主要短板是全库使用一个版本号（data ver）导致粒度不够细致，通过版本号只能决定同步上传和下载方向，方向决定以后就是 file list diff 覆盖，场景举例：

A 设备上修改文件 a 和新增 c 后 data ver 为 5，B 设备上修改文件 b 后 data ver 为 6，云端 data ver 3,。触发 A 同步以后云端数据会被 A data 覆盖（A 和云端一致），然后触发 B 同步以后云端数据再被 B data 覆盖（因为 B data ver 6 大于云端 5，B 和云端一致），这时再次触发 A 同步会进行下载，导致 A 文件 a 的修改被还原为 B 上的 a，新增的 c 被删除。此时这个分布式系统中节点（A、B 和云端）的状态是一致的，都是 data ver 6，虽然满足了一致性，但是这显然不是用户期望的。

用户期望的结果应该是 A 的 a 文件修改和新增 c 文件以及 B 的 b 文件修改能够同步到所有设备上。也就是触发 B 同步时不要直接覆盖云端，而是先 pull 云端变更并进行合并到 B 上，然后再执行上传覆盖云端。

按照这个思路的实现是使用 data ver 决定同步方向的同时在文件列表索引（sync/index.json） 中引入每个文件版本号（file ver），用 ver 可以对比文件粒度的方向，如果要执行 upload 则先 download diff merge；如果要执行 download 则先 upload diff merge。

目前大致就考虑这么多，实现细节上还有待考虑，欢迎讨论。