Compose状态管理基础：mutableStateOf与StateFlow
从State说起
做Compose开发，绕不开状态管理。说白了，你得告诉框架“什么东西变了”，它才能去刷新界面。mutableStateOf和StateFlow都能干这事，但底层逻辑完全不一样。我个人习惯是：如果只是一个简单开关、一个数字计数器，就用mutableStateOf；一旦涉及数据流、异步操作、多个观察者，StateFlow会更顺手。
mutableStateOf：Compose的内建状态
这是Compose自带的反应式状态容器。你定义一个变量，用mutableStateOf(初始值)包裹，Compose会追踪它的读取和写入。当值改变时，所有读取该状态的Composable都会重组。
@Composable
fun Counter() {
var count by remember { mutableStateOf(0) }
Button(onClick = { count++ }) {
Text("点击次数: $count")
}
}这里有个关键点：remember保证重组时状态不被重置。我在项目中遇到过一个问题——忘记加remember，结果状态每次重组都回到初始值，排查了半天。
StateFlow：Kotlin协程的响应式数据流
StateFlow是Kotlin协程库里的东西，本质是一个可观察的冷流变体。它的特点是：持有最新值，且多个收集者可以共享同一个数据流。在Compose里通过collectAsState()把它桥接到Compose状态。
class ViewModel {
private val _uiState = MutableStateFlow("初始状态")
val uiState: StateFlow<String> = _uiState.asStateFlow()
fun update(newText: String) {
_uiState.value = newText
}
}
@Composable
fun MyScreen(viewModel: ViewModel) {
val state by viewModel.uiState.collectAsState()
Text(state)
}StateFlow天生适合与协程配合。比如后台定时刷新数据、网络请求结果推送，用StateFlow可以优雅地把异步数据变成界面状态。我曾经在离线数据同步场景里用StateFlow管理同步进度，配合catch和retry，处理异常非常方便。
关键区别与选择
| 维度 | mutableStateOf | StateFlow |
|---|---|---|
| 所属范围 | Compose Runtime | Kotlin协程 |
| 线程安全 | 默认只在Compose安全，跨线程需加锁 | 天生线程安全（通道+互斥） |
| 观察者机制 | 隐式重组追踪 | 显式collect / collectAsState |
| 是否独立于Compose | 只能在Compose作用域存活 | 完全独立，可在ViewModel / Service中使用 |
| 适用场景 | 简单UI局部状态 | 跨层数据流 / 异步数据 / 多订阅 |
实战案例：离线数据同步中的状态选择
假设我们做一个离线数据同步功能。同步进度、错误信息、同步开关等几个状态该怎么选？
- 同步开关（是否允许自动同步）：单个布尔值，只影响一个开关组件。用
mutableStateOf，干净利落。 - 同步进度百分比：实时变化，需要刷新进度条。但也只在当前界面用，同样用
mutableStateOf即可。 - 同步结果列表：可能来自后台Service，多个界面（设置页、通知栏）都要观察。必须用
StateFlow，通过ViewModel暴露出来。
看看，这就是“因地制宜”。盲目全部用StateFlow会增加不必要的协程开销；全部用mutableStateOf又会在跨组件传递时失控。
MutableStateFlow的value直接暴露给Composable，然后无意中在多个协程里同时修改value，导致中间状态丢失。后来我才意识到，StateFlow的value写操作是非线程安全的——虽然它内部用了互斥锁保证原子性，但如果你在多个协程里并发赋值，最后写入的会覆盖之前的。正确的做法是用update { ... }原子操作，或者用map / combine做变换。
别忘了生命周期
mutableStateOf依赖Compose的重组生命周期，如果Composable退出重组，状态自然回收。StateFlow不同——它活在协程里，你需要手动取消协程作用域。否则即使界面已经销毁，StateFlow还在后台跑，浪费资源。我在项目里就见过泄漏的StateFlow，导致后台一直发请求。解决办法：在ViewModel的onCleared()里取消协程，或者用viewModelScope自动管理。