在当今云服务无处不在的时代，构建完全离线可用的“本地优先”（Local-First）应用程序似乎是一种逆流而上。然而，Local-First 架构承诺了无与伦比的性能、数据所有权和隐私性。其核心挑战在于：当多个设备在离线后各自修改数据，重新连接时如何实现无缝、无冲突的数据同步？答案在于将无冲突复制数据类型（CRDT）的强大理论与无处不在的 SQLite 数据库相结合。
本文将深入探讨这一组合的技术实现，阐述如何通过 SQLite 拦截数据变更，利用 CRDT 原理记录因果关系，并最终实现一个健壮的、能够自动解决冲突的同步引擎。
核心思想：拦截、分解与记录
实现 Local-First 同步的第一步，是在数据源头——本地数据库——捕获每一次变更。直接对数据库进行轮询效率低下且不可靠。一种更优雅的方案是利用 SQLite 内置的触发器（Triggers）机制。我们可以为需要同步的每一张用户表（例如 todos 表）设置 INSERT、UPDATE 和 DELETE 触发器。
当用户执行一个 SQL 操作时，例如：
UPDATE todos SET status = 'completed' WHERE id = 'task-123';
相应的触发器会被激活。然而，仅仅知道“某一行被更新了”是远远不够的。为了实现精细化的冲突合并，同步引擎需要将这个行级操作分解为列级操作。这是因为 CRDT 的一个关键优势在于，它允许不同设备同时修改同一行数据的不同列而不会产生冲突。例如，Alice 在离线时修改了任务的标题，而 Bob 修改了任务的状态，这两个操作应当能被安全地合并。
因此，触发器触发的逻辑会将上述 UPDATE 操作转化为一个原子性的“列变更”事件，大致包含以下信息：(row_id: 'task-123', column: 'status', value: 'completed')。
捕获到列级变更后，我们必须为其附加足够多的因果元数据，以便在未来的同步过程中正确地排序和合并。这些元数据是 CRDT 算法的基石，通常存储在一个独立的、对用户隐藏的 metadata 或 crdt_log 表中。
每一条变更记录通常包含以下关键字段：
site_id: 设备的唯一标识符。例如，Alice 的手机是 site-A，Bob 的笔记本是 site-B。这用于追溯变更的来源。column_version: 通常使用兰伯特时钟（Lamport Clock）或混合逻辑时钟（HLC）实现的列版本号。该时钟确保来自同一设备的变更可以被完全排序。每次设备写入时，时钟值都会增加。db_version: 数据库范围的逻辑时钟。它代表了数据库的整体状态，用于快速判断一个设备是否已经包含了另一个设备的某些变更，从而在同步时高效地计算出需要传输的变更集（delta）。op_type: 操作类型，标记此次变更是 INSERT、UPDATE 还是 DELETE。value: 变更后的新值。
通过将这些元数据与变更本身绑定，我们创建了一个带有完整因果历史的日志。当 Alice 修改任务状态时，她的设备会在 crdt_log 表中插入一条记录，其中包含了她的 site_id 和一个递增后的版本号。
同步与冲突解决策略
当设备重新联网时，同步阶段开始。过程大致如下：
- 差异计算（Diff Calculation）: 设备之间首先交换它们所知道的关于其他所有设备的最新
db_version。例如，Alice 的设备会询问 Bob：“你从 site-A（Alice 的设备）看到的最新版本是什么？” Bob 回复后，Alice 就可以只发送此版本之后的所有变更，极大地减少了网络负载。
- 变更传输（Operation Shipping）: 设备将计算出的差异（即
crdt_log 表中的新行）打包发送给对端。
- 操作重放（Replay）: 接收方按因果顺序（通常是按
db_version 和其他时钟元数据排序）应用这些变更。在重放期间，冲突解决逻辑会生效：
- 不同列的并发修改：自动合并，因为它们是独立的变更。
- 相同列的并发修改：发生真正的冲突。此时，CRDT 的确定性规则介入。最常见的规则是“后来者优先”（Last-Writer-Wins），即拥有更高
column_version（或 site_id 更大，以打破时钟平局）的变更会覆盖旧值。由于所有设备都遵循相同的规则，它们最终会收敛到一致的状态。
如何处理删除操作：逻辑删除（Tombstones）
在分布式系统中，直接执行 DELETE FROM ... 是非常危险的。如果一个设备删除了某条记录，而另一个离线设备在不知情的情况下更新了这条记录，当后者上线同步时，已删除的数据可能会“复活”。
正确的处理方式是使用逻辑删除，也称为“墓碑”（Tombstone）。当用户删除一条记录时，我们不是从数据库中物理移除它，而是在 crdt_log 中为该记录创建一个 op_type = 'DELETE' 的条目。这个墓碑记录同样带有时钟元数据。
当其他设备同步到这个墓碑时，它们会将本地的对应数据标记为已删除。如果之后收到对已删除记录的更新，同步引擎会检查其版本号。如果更新的版本号低于删除操作的版本号，该更新将被安全地忽略，从而防止数据复活。这些墓碑记录需要被保留，直到系统可以确认所有设备都已接收到该删除操作，之后才能进行垃圾回收（GC）以释放存储空间。
结论
通过在 SQLite 之上构建一个由 CRDT 驱动的同步层，我们可以创建一个体验流畅、始终可用的 Local-First 应用程序。其核心在于利用 SQLite 触发器自动捕获变更，将其分解为带有因果元数据的列级操作，并存储于一个不可变的日志中。在同步时，通过交换和重放这些日志条目，系统能够自动合并并发编辑并以确定性的方式解决冲突，最终达到强最终一致性（Strong Eventual Consistency）。
这种架构将数据同步的复杂性从应用开发者手中解放出来，使其能够专注于核心业务逻辑，同时为用户提供一个无论网络状况如何都能可靠工作的应用程序。正如 Marco Bambini 在其文章 《The Secret Life of a Local-First Value》 中所展示的，这套机制是实现真正离线优先、安全合并和响应迅速的现代应用的关键。