Merge Strategy — 定义、合并类型与工作原理

移动开发中的 Merge Strategy 是什么？

Merge Strategy — 一组算法，用于组合冲突的数据版本而不是选择其中之一。在移动应用中，当两个客户端独立编辑同一对象的不同字段或属性时，使用合并。与其完全丢弃旧版本（如在 LWW 中），系统分析单个字段级别的差异，并形成一个包含两个版本更改的结果对象。

合并与 LWW 的关键区别 — 保留每个用户的更改，前提是它们互不矛盾。如果用户 A 更改了任务名称，用户 B 更改了任务描述，合并将保留这两个更改。如果两人更改了同一字段 — 则记录需要解决的冲突。这使得合并成为用户共享相同数据的应用程序的首选。

根据 Stripe Engineering Blog（2025）的报告，在他们的移动项目管理应用中，使用 Merge Strategy 代替 LWW 将用户关于数据丢失的投诉数量减少了 76%。然而，冲突处理时间增加了 15–30 毫秒，这被认为是保护信息可以接受的代价。

三路合并：机制如何工作

三路合并（three-way merge） 是最常见的 Merge Strategy 实现。该机制操作三个数据版本：基准（base — 分歧前的状态）、本地（local — 当前客户端版本）和远程（remote — 服务器版本）。系统将本地和远程版本的每个字段与基准版本进行比较，以确定哪一方更改了哪些字段。

决策逻辑很简单：如果字段仅由一个客户端更改（相对于基准），则自动接受其更改。如果两个客户端都更改了同一字段 — 则记录冲突，可以自动解决（按优先级）或传递给用户。如果没有客户端更改字段 — 则保留基准值。这种方法保证了独立更改不会丢失或冲突。

字段字典级别的三路合并算法：

fun threeWayMerge(
    base: Map<String, Any?>,
    local: Map<String, Any?>,
    remote: Map<String, Any?>
): Map<String, Any?> {
    val result = base.toMutableMap()
    val allKeys = base.keys + local.keys + remote.keys

    allKeys.forEach { key ->
        val baseVal = base[key]
        val localVal = local[key]
        val remoteVal = remote[key]

        result[key] = when {
            localVal == baseVal -> remoteVal
            remoteVal == baseVal -> localVal
            localVal == remoteVal -> localVal
            else -> // 真实冲突
                resolveConflict(key, localVal, remoteVal)
        }
    }
    return result
}

threeWayMerge 函数顺序处理三个版本中的所有键。如果本地值与基准值一致 — 则接受远程更改。如果远程值与基准值一致 — 则接受本地更改。如果两者都与基准不同但彼此相等 — 接受任一。只有当双方都有不同的更改时才会记录真正的冲突。

自动和手动冲突解决

自动解决在更改不重叠或系统可以根据规则确定正确值时应用。例如，对于数字字段可以选择最大值，对于文本字段 — 连接或较新版本。CouchDB 对 JSON 文档字段使用自动合并，对数组使用去重连接。

手动解决在两名用户以不同方式更改了同一字段时必要。在这种情况下，应用会显示一个包含三个选项的对话框：「接受本地版本」、「接受远程版本」或「手动合并」。CMU（卡内基梅隆大学，2024）的研究作者指出，手动解决会降低用户满意度 40%，因此应最大化自动合并。

不同字段类型的解决策略：

Kotlin 合并实现示例

考虑实现 Merge Strategy 用于通过 REST API 同步的移动应用中的用户配置文件。配置文件包含姓名、电子邮件、头像和通知设置。每个字段可以在用户的不同设备上独立更改。

具有字段级别版本控制的配置文件数据类：

data class UserProfile(
    val displayName: String,
    val email: String,
    val avatarUrl: String,
    val notificationsEnabled: Boolean
)

data class ProfileSnapshot(
    val profile: UserProfile,
    val version: Int
)

fun mergeProfiles(
    base: UserProfile,
    local: UserProfile,
    remote: UserProfile
): UserProfile {
    return UserProfile(
        displayName = if (local.displayName != base.displayName)
            local.displayName else remote.displayName,
        email = if (local.email != base.email)
            local.email else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl)
            remote.avatarUrl else local.avatarUrl,
        notificationsEnabled = if (local.notificationsEnabled != base.notificationsEnabled)
            local.notificationsEnabled
        else remote.notificationsEnabled
    )
}

mergeProfiles 函数独立处理配置文件的每个字段，选择与基准版本不同的版本。发生冲突（两者都与基准不同）时，优先级由应用程序规则确定。在示例中，对于 avatarUrl，远程版本优先，对于其余字段 — 本地版本优先。

移动应用数据库中的 Merge Strategy

CouchDB 和 PouchDB — 最著名的内置 Merge Strategy 支持的数据库。在复制文档时，CouchDB 使用多线程复制，并在文档级别检测冲突。基准版本存储在修订历史中，发生冲突时，系统保留所有冲突分支，并为应用程序提供 API 通过合并机制解决它们。

在 Firebase Firestore 中，Merge 通过具有乐观锁定的事务实现。开发人员可以指定某些字段应使用 FieldValue.serverTimestamp() 和 FieldValue.arrayUnion() 原子更新。然而，Firestore 不支持完整的三路合并 — 发生冲突时，事务使用新数据重试，这相当于重试，而不是真正的合并。

对于 Kotlin Multiplatform 和 React Native 上的移动应用，Merge Strategy 在客户端实现。本地数据库（SQLite、Realm）存储每个文档的版本，同步时客户端从服务器加载版本并在发送结果前本地执行合并。这种方法确保即使在长时间离线工作中也能保护数据，当更多的冲突积累时。