3. 状态提升 vs 状态下沉：适用场景对比、决定因素分析
在掌握状态提升的核心理念后，开发者最常遇到的困惑是：什么时候应该提升到父级，什么时候反而应该下沉到子级？ 这两种模式并非二元对立，而是对应着不同的封装粒度与数据流诉求。本章从适用场景与决定因素两个维度进行系统对比，帮助你建立直觉判断。
核心决策依据：状态的 复用范围 与 变化频率。复用范围越广，越需要提升；变化频率越高，越需要下沉以避免父组件不必要的重组。
概念速览：两种流向
- 状态提升（Hoist）： 将状态迁移到调用方或最近的共用父组件，通过参数向下传递状态，通过回调向上传递事件。数据流呈现清晰的“自上而下、自下而上”循环。
- 状态下沉（Sink）： 将状态保留在或迁移到更具体的子组件 / 子树内部的 ViewModel 或
remember中，降低父组件的耦合度与重组影响范围。
适用场景对比表
| 维度 | 状态提升 | 状态下沉 |
|---|---|---|
| 数据共享 | 多个兄弟 / 远亲组件需要同一份数据 | 数据仅属于单个组件或其内部子组件的自包含逻辑 |
| 组件复用 | 父组件需要控制子组件状态（受控组件） | 子组件自身管理状态，对外只暴露行为（非受控组件） |
| 性能优化 | 状态提升可能导致父组件频繁重组，需配合 derivedStateOf 或 snapshotFlow |
状态下沉可以天然隔离重组范围，显著提升列表 / 复杂布局的滚动性能 |
| 测试难度 | 状态逻辑集中在 ViewModel 或父组件，便于编写纯函数单元测试 | 状态逻辑分散在各子组件，可能需要组合测试或状态注入 |
| 架构清晰度 | 符合单一真相来源原则，数据流可追溯 | 封装性更好，组件内部修改不影响外部，职责边界明确 |
决策流程图
以下流程图帮助你快速判断应当提升还是下沉：
常见误区
误区1：所有状态都应当提升到最高层级。
这会导致“状态地狱”，父组件持有大量无关状态，参数层层透传，降低可维护性与编译安全性。
误区2：状态下沉就是不用状态管理。
下沉仍然可以使用 ViewModel 或 remember，只是状态的作用域限定在该子树内部，并非“没有管理”，而是更精细化的职责划分。
误区3：提升与下沉只能二选一。
实际项目中常见混合模式：核心数据提升，UI 细节下沉；或者通过回调将事件下沉到子组件，而数据源仍留在父级。
决定因素分析
判断使用提升还是下沉，可以依次回答以下三个问题：
- 这个状态是否被多个不相关的组件共享？ 是 → 提升；否 → 进入下一步。
- 这个状态的变化是否应当由外部触发？ 是 → 提升（受控组件）；否 → 进入下一步。
- 将这个状态放在子组件中是否会造成父组件不必要的重组？ 是 → 下沉；否 → 保留在当前层级。
以下骨架示例展示了提升与下沉的代码组织形式差异：
// 状态提升：状态与回调通过参数传递
@Composable
fun Parent() {
var count by remember { mutableStateOf(0) }
Child(count = count, onIncrement = { count++ })
}
// 状态下沉：状态在子 Composable 内部管理
@Composable
fun Parent() {
Child()
}
@Composable
fun Child() {
var count by remember { mutableStateOf(0) }
// ...
}练习题：场景判断
场景：你有一个 LazyColumn，每一项都有一个 LikeButton。点赞状态（是否已赞、点赞数）是否应当提升到 LazyColumn 所在的 Screen 层级？
分析：
- 如果点赞状态需要用于“全部点赞”或“统计点赞总数”，则应当提升到 Screen 层级（或 ViewModel 层）。
- 如果点赞状态仅用于改变当前 Item 的图标和数字，则应当下沉到 Item 的内部状态或 Item 自己的 ViewModel 中，避免某个 Item 的点赞行为导致整个列表重组。
结论：大多数情况下，列表 Item 的点赞状态适合下沉，以保证列表滚动性能。
应用边界
- 需要提升：跨层级共享状态（如用户信息、主题设置）；表单的多个字段需要集中校验；需要保持单一真相来源的场景。
- 适合下沉：UI 部件的内部动画状态；列表 Item 的独有交互状态；高度内聚的自定义 Composable 组件，且不存在外部消费者。
- 灰色地带：当提升与下沉的界限模糊时，优先遵循 最小权限原则——将状态放到刚好够用的最低公共层级。这个层级既不是最高的 Screen，也不是最低的 Button，而是它们之间的一个组合容器（如
Card或Section），既能满足共享需求，又不至于造成无关重组。