承接上一篇《UseCase 与领域层：要不要为每个页面写一层》，上一篇把业务编排放在了 UseCase 里，但界面层还有一团乱麻等着收拾：状态和事件混在一起、旋转屏幕后重复弹窗、退出登录后状态没清干净。这些问题的共同根因只有一个——没有把「界面现在是什么」和「界面发生了什么」分开建模。结论先行：单向数据流的落地只需要一件事——把界面能读的东西归为 State（可重放、幂等），把界面能做一次的事归为 Event（一次性的、不可重放）。判断标准非常朴素：旋转屏幕后，这个东西该跟着重建吗？该跟着重建就是 State，不该就是 Event。一、为什么必须分：旋转屏幕这个照妖镜Android 的配置变更会重建 Activity，但 ViewModel 存活。如果把两者混在一个data class UiState里，问题立刻出现。// ❌ 把「一次性事件」塞进 State data class UiState( val loading: Boolean = false, val userName: String = "", val showLoginSuccessToast: Boolean = false, // 事件混进来了 val navigateToHome: Boolean = false // 导航也混进来了 )触发一次登录成功后：fun onLoginClicked() { 
长河君 · 2026/11/6 5:16:58 · 阅读 1.2k 第318篇 单向数据流实践：State 与 Event 分离
承接上一篇《UseCase 与领域层：要不要为每个页面写一层》，上一篇把业务编排放在了 UseCase 里，但界面层还有一团乱麻等着收拾：状态和事件混在一起、旋转屏幕后重复弹窗、退出登录后状态没清干净。这些问题的共同根因只有一个——没有把「界面现在是什么」和「界面发生了什么」分开建模。结论先行：单向数据流的落地只需要一件事——把界面能读的东西归为 State（可重放、幂等），把界面能做一次的事归为 Event（一次性的、不可重放）。判断标准非常朴素：旋转屏幕后，这个东西该跟着重建吗？该跟着重建就是 State，不该就是 Event。一、为什么必须分：旋转屏幕这个照妖镜Android 的配置变更会重建 Activity，但 ViewModel 存活。如果把两者混在一个data class UiState里，问题立刻出现。// ❌ 把「一次性事件」塞进 State data class UiState( val loading: Boolean = false, val userName: String = "", val showLoginSuccessToast: Boolean = false, // 事件混进来了 val navigateToHome: Boolean = false // 导航也混进来了 )触发一次登录成功后：fun onLoginClicked() {