Jetpack Compose中ViewModel直接使用MutableState存储状态是否可行？

首先可以明确的是，你给出的代码是完全合法且有效的，在纯Compose的简单业务场景下这种写法没有任何问题，运行效果完全符合预期，谷歌官方的Compose文档里也提到过允许在ViewModel中直接使用State类型存储状态。

class MyViewModel: ViewModel() {
    val showDialog = mutableStateOf(false)
}

@Compose
fun MyScreen(viewModel: MyViewModel) {
    Button(onClick = { viewModel.showDialog.value = true })
    if (viewModel.showDialog.value) {
        AlertDialog(...)
    }
}

大家更习惯用MutableStateFlow而非直接用mutableStateOf，主要是出于以下几个实际场景的考量：

• 跨场景复用能力更强：State是Jetpack Compose专属的API，只能在Compose环境下被观测。如果你的ViewModel需要对接非Compose的View体系、或者在KMM跨端项目中共享逻辑，Flow是Kotlin标准库提供的能力，所有Kotlin环境都可以直接订阅，不会被绑定在Compose技术栈上。
• 复杂数据流处理更方便：Flow原生提供了非常多的操作符，比如debounce防抖、map状态转换、combine合并多个数据源、filter过滤无效状态等，要实现复杂的状态处理逻辑不需要自己手写额外的监听代码，直接调用操作符就能完成，开发效率更高。
• 生命周期管控更灵活：Flow可以通过stateIn方法自定义共享策略，比如配置页面退到后台时自动停止发送状态更新、缓存多少条历史状态等，能更好的适配不同的性能优化需求，直接用mutableStateOf的话状态更新不受生命周期管控，复杂场景下可控性更弱。
• 团队规范统一成本低：如果项目同时存在Compose和传统View两种页面，统一用Flow作为ViewModel的状态输出层，所有页面的状态订阅规则保持一致，不需要维护两套状态规范，降低团队的学习和维护成本。

如果你的项目是纯Compose项目，业务逻辑也比较简单，完全可以直接在ViewModel中用mutableStateOf存状态，没有任何强制要求必须使用Flow，两种方案只是适配的场景不同，没有绝对的对错。

内容的提问来源于stack exchange，提问作者Lucas Mann