为什么在 MVVM 中推荐使用 MutableLiveData 而非 LiveData？
解读
面试官抛出此题，并非单纯考察“能不能改值”，而是看候选人是否理解：
- LiveData 的“只读”语义在架构层面的价值；
- MutableLiveData 的“可写”权限为何必须被收敛到 ViewModel 内部；
- 如果直接在层与层之间传递 MutableLiveData，会打破哪几条 Clean Architecture 原则；
- 在国内大厂代码评审与组件化仓库的实测门禁中，这一条为何会被标记为 Blocker。
一句话：考察“可变”与“不可变”的边界意识，以及由此带来的可测试、可维护、可并行开发收益。
知识点
- LiveData 是抽象类，其 setValue/postValue 为 protected，外界只能 observe，天然只读。
- MutableLiveData 将上述方法公开成 public，提供“写”能力。
- MVVM 分层职责：
- View 只消费状态，不应改状态；
- ViewModel 持有状态并负责业务逻辑；
- Model 负责真实数据源。
- 暴露只读 LiveData 给 View，可强制“单向数据流”，杜绝 View 偷偷改状态导致的不可预期 BUG 与线程安全问题。
- 单元测试角度：对外只读时，测试用例只需验证 ViewModel 在特定输入下是否发射了期望值，无需防备外部篡改。
- 组件化/模块化角度：模块 A 若把 MutableLiveData 暴露给模块 B，相当于把“写”权限扩散，后续重构成本剧增；国内仓库的 lint-rules（如阿里、美团、腾讯开源的仓库检测插件）会直接拦截。
- 编译期约束优于口头规范：Kotlin 的 backing-property 写法
private val _count = MutableLiveData<Int>() val count: LiveData<Int> = _count
让“写”与“读”在编译器层面分离，零成本、零歧义。 - 与 Compose State 的映射：将来迁移到 Compose 时，ViewModel 对外暴露的 State<T> 同样要求“只读”，提前养成习惯可减少迁移阻力。
答案
在 MVVM 中，ViewModel 既要“写”状态又要“读”状态，而 View 只能“读”状态。
MutableLiveData 提供了 public 的 setValue/postValue，因此只能在 ViewModel 内部作为私有字段使用；
对外则应暴露不可变的 LiveData，利用编译器强制 View 层无法修改数据，从而：
- 保证单向数据流，杜绝状态被外部篡改；
- 降低并发与生命周期异常带来的副作用；
- 提升单元测试的稳定性与可读性；
- 符合国内大型项目的代码门禁与模块化规范。
因此，MVVM 中推荐“ViewModel 内部用 MutableLiveData，外部返回 LiveData”，而不是直接把 MutableLiveData 交给上层。
拓展思考
-
在团队规模膨胀、多人并行开发场景下，若允许 Activity/Fragment 拿到 MutableLiveData，最常见的崩溃是“后台线程直接 setValue”导致的
java.lang.IllegalStateException: Cannot invoke setValue on a background thread
暴露只读 LiveData 能从根本上消除该隐患。 -
如果业务需要“事件”而非“状态”，应使用 LiveData<Event<T>> 或 SharedFlow/MutableSharedFlow，并同样保持“写”权限封闭在 ViewModel，避免“事件被重复消费”争议。
-
在 Kotlin 协程大行其道的当下，很多项目已用 StateFlow/SharedFlow 替换 LiveData，但“对外只读、对内可写”的思路依旧成立：
private val _uiState = MutableStateFlow(UiState()) val uiState: StateFlow<UiState> = _uiState
这一 backing-property 模式与 LiveData 完全一致，说明“可变与不可变的边界”是架构设计的通用语言，而非 LiveData 独有。 -
面试加分项：可以补充“国内插件化框架对反射修改 MutableLiveData 的检测”，指出即使通过反射强行修改，也会被美团 Robust、微信 Tinker 等热修框架的签名校验拦截，进一步证明“暴露只读”是安全、合规、可审计的最佳实践。