边缘同步的 CRDT 实践：96% 到 99% 的可用性背后，是“合并”而不是“投票”

离线优先的边缘应用面对一个传统 Web 应用不需要处理的问题：设备可能长时间断网，本地写入必须成功，重连后必须合并，而且合并结果在所有副本上必须一致。2026 年的 CRDT 实践给出了一些可量化的结果。

一项针对间歇连接场景的 CAMS F Edge DTN 架构报告：在间歇连接下维持 96% 到 99% 的操作可用性，完全离线时达到 100% 可用性，本地推理中位延迟低于 10ms，通过 CRDT 同步实现确定性状态收敛。另一条路线是 SQLite 的离线同步栈：SQLite-Sync 把任何 SQLite 数据库变成一个无冲突、离线优先的副本，通过 CRDT 自动与 SQLite Cloud 节点同步；CloudSync 在重连时自动合并离线变更，确定性地处理冲突，保证最终一致，不需要复杂的合并逻辑。

这些方案的核心不是“自动解决冲突”，而是把冲突的定义从“谁赢”变成“如何合并”。CRDT 的数学性质保证了：只要所有副本最终收到相同的变更集，它们会独立计算出相同的状态，无论变更到达的顺序如何。这对于离线场景是本质性的：你无法在离线时“投票”决定哪个版本是权威的，因为设备之间没有通信；你只能让每个设备在本地接受写入，然后在重连时让数据结构本身保证合并的确定性。

代价也需要说清楚。CRDT 的元数据随变更历史增长，需要垃圾回收或压缩策略；不是所有数据类型都有高效的 CRDT 实现，复杂业务对象（比如一个有状态的订单）可能需要拆成多个 CRDT 字段，或者接受 LWW 的粗粒度合并。SQLite-Sync 目前实现的 CRDT 算法是 LWW 和 Grow-Only Set，这覆盖了“最后写入获胜”和“只增不减的集合”两类场景，但不覆盖所有冲突语义。如果你的业务需要“两个用户同时修改同一张订单的不同字段，都要保留”，LWW 会丢掉一个；如果业务可以接受字段级的最后写入获胜，LWW 是足够且简单的。

一个可操作的判断是：如果你的离线场景主要是内容创建、笔记、任务清单、表单草稿这类“每个字段独立、合并语义简单”的数据，LWW 加 CRDT 的轻量实现是合适的起点；如果涉及库存扣减、金融交易、多步审批这类需要业务规则裁决的冲突，纯 CRDT 的“自动合并”不够，需要把冲突暂存下来，让业务规则或人工来决定。边缘同步的起点不是“选哪个 CRDT 库”，是“先定义你的数据在离线时允许什么样的合并语义”。