Kotlin Flow：combine()、merge() 和 zip() 的区别 —— 不要再互相替代使用

如果你曾疑惑：为什么你的 Compose UI 突然不再更新、为什么某个 Flow 的 collector 被触发得异常频繁，或者为什么一个数据流莫名其妙地阻塞了另一个，那么问题可能并不在业务逻辑，而是你选择的 Flow 操作符。

在响应式 Android 开发中，错误地选择操作符会带来架构层面的阻力。使用错误的工具可能导致：

UI 更新停滞
竞态条件（Race Condition）
过度重组（Excessive Recomposition）

这些问题不仅会消耗电量，还会降低用户体验。

"错误选择的代价" 表

1. combine()：状态快照架构师

combine 是现代 ViewModel 的核心，因为 UI 本质上是由"状态快照"驱动的。一个页面通常需要同时获得完整的数据视图，例如：

搜索关键字
已选择的筛选条件
数据内容

初始化同步

combine 会等待所有上游 Flow 至少发射（emit）一次数据。

这也是为什么 StateFlow 与它配合得如此自然------因为 StateFlow 是一种"热流（hot flow）"，总是带有初始值，因此能够立即完成这一步初始化同步。

在初始同步之后，只要任意数据源更新，它就会发出新的状态快照。

发射模式：

less 复制代码

Flow A: 1 --- --- 2 --- --- --- --- 3
Flow B: A --- --- --- --- B

combine:
1A, 2A, 2B, 3B

代码示例：

kotlin 复制代码

val searchQuery = MutableStateFlow("")
val selectedCategory = MutableStateFlow(Category.ALL)

val items = repository
    .getItemsFlow()
    .stateIn(
        viewModelScope,
        SharingStarted.Lazily,
        emptyList()
    )

val displayState = combine(
    searchQuery,
    selectedCategory,
    items
) { query, category, list ->

    // 所有 Flow 首次发射后，
    // 任意数据源变化都会重新执行

    list.filter {
        it.matches(query, category)
    }
}

2. merge()：事件漏斗

merge 不会对数据发射做任何语义上的协调。

它把每一个输入值都视为独立事件，就像一个漏斗一样，将多个数据流汇聚成一个。

并发特性

merge 会并发收集（collect）所有上游 Flow。

虽然操作符本身是线程安全的，但由于数据发射是并发进行的，如果你的 collector 操作了不安全的共享可变状态（shared mutable state），就有可能产生竞态条件。

代码示例：

scss 复制代码

val clickEvents =
    button.clicks()
        .map { UiEvent.Refresh }

val shakeEvents =
    sensor.shakes()
        .map { UiEvent.Refresh }

// 并发转发所有事件
// 顺序不保证

val refreshTrigger =
    merge(clickEvents, shakeEvents)

refreshTrigger.collect { event ->
    repository.refreshData()
}

事件到达后会被独立处理。

3. zip()：位置匹配器

zip 是严格的一对一协调操作符。

它根据数据的位置进行匹配：

Flow A 的第 n 次发射
对应 Flow B 的第 n 次发射

完成规则（Completion Rule）

只要某个上游 Flow 完成，并且已经无法形成新的配对，zip 就会立即结束。

例如：

如果：

Flow A 发射 10 次
Flow B 发射 3 次后结束

则最终结果：

只产生 3 组配对
Flow 随即结束

发射模式：

less 复制代码

Flow A: 1 --- --- 2 --- --- --- --- 3
Flow B: A --- --- --- --- B

zip:
1A, 2B

代码示例：

ini 复制代码

val questions = flowOf(
    "2 + 2?",
    "法国首都是？"
)

val answers = flowOf(
    "4",
    "Paris"
)

val quizFlow =
    questions.zip(answers) { q, a ->

        QuizItem(
            question = q,
            answer = a
        )
}

应该选择哪个操作符？

是否需要获取多个数据源的最新状态？→ combine()

是否只是希望把多个独立事件合并到一个流？→ merge()

数据是否需要严格一一对应？→ zip()

不建议使用的场景

避免直接对高频数据流使用 combine()

如果上游数据频繁变化，下游可能会触发大量更新。

可以使用：

scss 复制代码

sample()
debounce()

降低更新频率。

避免在以下场景使用 merge()：

顺序很重要
后续事件依赖前一个事件结果

可考虑：

scss 复制代码

flatMapConcat()

进行串行处理。

避免在对 UI 响应性要求高的场景使用 zip()

如果某个数据源较慢，UI 更新可能会无限等待对应数据。

常见问题（FAQ）

combine() 和 zip() 最核心的区别是什么？

combine()：

任意上游 Flow 更新都会触发
使用其它 Flow 最新缓存值
非常适合 UI 状态管理

zip()：

严格按位置配对
第一项对应第一项
第二项对应第二项
某个 Flow 结束时整体结束

适合处理同步配对数据。

最终总结

大多数 Flow 的问题并不是语法错误，而是选择了错误的响应式模型：

scss 复制代码

combine() → 状态同步（State Synchronization）

merge() → 事件聚合（Event Aggregation）

zip() → 位置配对（Positional Pairing）

当你根据数据本身的特性来选择操作符时，你的 Android 架构会变得：

更简单
更可预测
更容易扩展