为何需要State Hoisting：解决状态共享、避免状态冗余、提升可测试性、降低耦合
在MVVM架构中，多个ViewModel或UI组件经常需要访问同一份业务状态。如果每个组件各自持有状态副本，必然导致数据不一致、重复计算和测试困难。State Hoisting（状态提升）正是针对这些问题的架构范式——将共享状态上移至更高层级（通常为父级ViewModel或全局状态容器），通过单向数据流向下分发，向上报告事件。
3.1 四个核心动因
核心认知：State Hoisting 不是“把代码搬个位置”，而是重新划分状态边界与信任链路。它迫使你明确每个状态的生命周期归属、修改权限和观察范围。
| 动因 | 问题表现 | Hoisting 如何解决 |
|---|---|---|
| 状态共享 | A、B两个Widget都需要显示“当前用户余额”，各自从网络拉取，更新不同步 | 将 |
| 避免状态冗余 | 多个ViewModel各自维护“筛选词”和“列表数据”，导致筛选逻辑重复、内存浪费 | 状态只存在一处（顶层ViewModel或Store），下游仅声明派生计算 |
| 提升可测试性 | 分散状态导致需要mock多个依赖，测试用例复杂 | 集中后的状态容器可以单独测试；UI层只验证输入/输出的映射 |
| 降低耦合 | 子组件直接持有父组件的状态引用，形成双向绑定链，修改牵一发动全身 | 子组件只通过Event回调向上报告意图，不直接修改外部状态 |
3.2 架构边界与分层职责
应用State Hoisting后，MVVM各层重新定义职责：
- UI层（Composable / View）：仅从提升后的状态读取数据，通过回调/事件向上转发用户意图。不持有可变状态。
- ViewModel层（父/子）：父级ViewModel作为状态拥有者，管理提升后的SharedFlow或StateFlow；子级ViewModel不保存副本，仅通过参数接收必要数据。
- Domain/Data层：无变化，纯业务逻辑与数据源。
验收标准（1/3）：项目中任何UI组件如果通过
remember { mutableStateOf() } 存储从网络/数据库获取的数据，必须迁移至父级ViewModel。遗留代码中不允许出现“两个组件各自调用同一条API并各自缓存结果”的情况。
3.3 数据流与控制流的变化
状态提升后，数据流变为严格单向：
父级ViewModel ──(State)──→ 子组件A
父级ViewModel ──(State)──→ 子组件B
子组件A ──(Event)──→ 父级ViewModel
子组件B ──(Event)──→ 父级ViewModel信任链路清晰：所有状态变更只能由父级ViewModel决策，子组件没有修改权。这消除了“谁改了这个状态”的调试难题。
3.4 内联 SVG：状态提升前后对比图
3.5 选型权衡与风险点
风险点警告：过度提升会破坏局部独立性。例如，一个仅用于弹出菜单的打开/关闭状态，硬提升到顶级ViewModel会增加参数传递复杂度。应遵循“最小提升范围”原则：状态只提升到能使所有需要它的组件共同访问的最小层级。
- 权衡1：提升层级越高，组件复用性可能降低（依赖外部状态）。方案：使用组合式继承，父级ViewModel提供状态，子组件以参数形式接收。
- 权衡2：提升后父级ViewModel职责增多，Single Responsibility可能违反。应对：将提升后的状态拆分为独立状态容器（Store），ViewModel仅负责协调。
- 权衡3：Event回调可能导致接口爆炸。方案：使用统一Action密封类，减少回调类型数量。
3.6 落地步骤与验收标准
落地步骤（第一阶段）
- 审计当前状态分布：搜索项目中所有
remember、LiveData、StateFlow的私有声明，找出超过一个消费者使用的状态。 - 确定提升点：选择
ViewModel层级（Activity对应ViewModel 或 Navigation Graph对应的Parent ViewModel）。 - 迁移数据源：将API/DB调用移至父级ViewModel，并将状态暴露为
StateFlow。 - 改造子组件：移除子组件的私有状态，改为接收来自父级的
StateFlow并触发Event回调。 - 移除冗余API调用：确保子组件不再直接发起同样的请求。
验收标准（全量）
| 维度 | 验收条件 | 检测方式 |
|---|---|---|
| 状态冗余 | 同一业务状态在VM层不存在超过一份副本 | 搜索 val + StateFlow 按类型去重，人工审查 |
| 测试覆盖 | 父级ViewModel单元测试覆盖所有状态变换；子组件测试仅Mock父级StateFlow | PR审查 + Sonar覆盖率报告 |
| 耦合度 | 子组件不可通过parentViewModel引用直接修改状态 |
禁止viewModel() 跨层级调用；lint规则检查 |
| 共享一致性 | 修改状态的所有入口均经过父级ViewModel，无遗漏 | 审计所有Event回调 |
进阶思维：State Hoisting 不仅仅是MVVM的专利，Compose架构中推荐将无状态组件放在底层，有状态Hoisting到调用方。这与MVVM的Hoisting思想完全同构——本质是将可变性上移，将不可变性下推。