stateflow和shareflow的区别
StateFlow 和 SharedFlow 都是 Kotlin 协程库中用于共享数据流的工具（均为 “热流”），但设计目标和使用场景有显著差异。以下是核心区别对比：
1. 核心定位
StateFlow是状态容器，专为持有和分发 “单一状态” 设计（如 UI 状态、用户信息、计数器值等）。它的核心是 “始终持有最新的状态值”，并确保新观察者能立即获取当前状态。
SharedFlow是通用的共享数据流，更灵活，可用于分发 “一系列事件或数据”（如实时日志、位置更新、多条消息等）。它不强制持有 “单一状态”，而是通过配置控制数据的缓存和分发策略。
2. 关键特性差异
| 特性 | StateFlow | SharedFlow |
|---|---|---|
| 初始值 | 必须有初始值（定义时需指定，如 MutableStateFlow(0)） | 可选（默认无初始值，按需配置） |
| 数据持有 | 始终持有最新的单个值（状态快照） | 不强制持有值，可通过 replay 配置缓存历史数据 |
| 新观察者行为 | 新观察者立即收到当前最新值（状态即时性） | 仅收到注册后发送的新数据（除非 replay > 0 缓存了历史值） |
| 数据更新方式 | 通过 value 属性直接修改（简洁，适合状态变更） | 通过 emit() 或 tryEmit() 发送数据（适合事件流） |
| 默认配置 | 固定为 replay = 1（仅缓存最新值）、无缓冲区 | 可配置 replay（缓存数量）、extraBufferCapacity（缓冲区大小）、onBufferOverflow（溢出策略） |
| 典型用途 | 存储和分发 UI 状态（加载中 / 成功 / 失败、列表数据等） | 分发一次性事件（如点击事件、通知）、多源数据流共享（如实时位置更新） |
3. 行为细节对比
（1）数据缓存与回放（replay）
StateFlow：固定replay = 1，即只缓存最新的一个值。无论何时注册观察者，都会先收到这个最新值（这是 “状态” 的核心需求：新观察者需要知道当前状态）。例：StateFlow保存计数器值5，新观察者注册后立即收到5。SharedFlow：replay可自定义（默认0）：replay = 0：不缓存任何数据，新观察者只收到注册后的新数据（适合一次性事件）。replay = 2：缓存最近 2 条数据，新观察者注册后会先收到这 2 条历史数据，再收新数据（适合需要回溯历史的场景，如日志流）。
（2）缓冲区与溢出策略
StateFlow：无额外缓冲区（extraBufferCapacity = 0），且溢出策略固定为 “挂起发送者”（确保状态更新不丢失）。因为状态必须是 “最新的”，不允许旧状态积压。SharedFlow：可通过extraBufferCapacity配置缓冲区大小（默认0），当缓冲区满时，通过onBufferOverflow指定策略：SUSPEND：挂起发送者，直到缓冲区有空间（默认，适合不希望丢失数据的场景）。DROP_OLDEST：丢弃最旧的数据，接收新数据（适合允许丢失旧数据的场景，如实时位置）。DROP_LATEST：丢弃新数据，保留旧数据（适合数据更新过快，只需处理最新值的场景）。
（3）数据更新的语义
StateFlow的value更新是 “覆盖式” 的：新值会直接替换旧值，观察者只会收到最新的结果（适合状态的 “当前快照”）。例：连续更新value = 1、value = 2，观察者最终只关心2。SharedFlow的emit()是 “追加式” 的：每个数据都会被分发（除非被缓存策略过滤），适合需要处理 “每一个事件” 的场景。例：连续emit(1)、emit(2)，观察者会依次收到1和2。
4. 使用场景选择
| 场景 | 推荐使用 | 原因分析 |
|---|---|---|
| 存储 UI 状态（如加载状态、列表数据） | StateFlow | 需要始终持有最新状态，新观察者（如页面重建后）需立即获取当前状态。 |
| 分发一次性事件（如跳转、弹窗） | SharedFlow（或 EventFlow） | 事件需被当时的观察者处理，新观察者不应收到历史事件（replay = 0）。 |
| 实时数据流（如位置更新、日志） | SharedFlow | 需分发一系列连续数据，可配置缓存策略（如缓存最近 3 条位置信息）。 |
| 状态组合（如合并多个状态为新状态） | StateFlow | 结合 combine 等操作符，轻松将多个状态流合并为新的状态流。 |
| 多观察者共享数据 | 两者均可，但 SharedFlow 更灵活 | SharedFlow 可通过配置满足不同观察者的需求（如部分观察者需要历史数据）。 |