React 状态上提与状态下沉
React 中状态上提与状态下沉的适用场景、取舍，以及它们如何影响共享逻辑和渲染边界。
#tech / dev / frame
#resource / react
#type / synthesis
#status / growing
[!info] related notes
React 状态上提与状态下沉
React 里“状态放在哪里”不是代码风格问题，而是共享关系、组件职责和渲染范围的共同结果。
一句话定义
状态上提是把多个组件共同需要的数据提升到它们的共同父层；状态下沉是把只服务局部交互的状态留在更靠近使用位置的组件里。
为什么这组概念要放在一起理解
- 它们都在回答同一个问题：状态到底该放哪
- 上提解决共享，下沉控制边界
- 真正好的设计通常不是极端选择，而是按使用范围决定位置
什么时候应该状态上提
- 多个兄弟组件需要读写同一份状态
- 某个交互结果要驱动多个区域联动
- 需要把共享状态作为单一事实来源维护
什么时候应该状态下沉
- 状态只影响局部 UI 交互
- 某个输入框、弹窗开关、hover 状态只在局部使用
- 放在父层只会扩大无关组件的重新执行范围
一个常见判断方法
- 先问谁真正需要这份状态
- 如果只有一个局部子树需要，就先别急着上提
- 如果多个并列组件都要消费，再考虑提到共同父层
常见误区
- 以为状态越集中越好
- 以为“减少 prop 传递”就一定要把状态提到更高层
- 只看共享关系，不看渲染传导范围和组件职责
最短记忆方式
共享需求推动上提，局部交互更适合下沉。
面试要点
来自 react-state-lifting-vs-state-colocation-interview-question 的面试视角整理。
一句话回答
如果多个组件需要共享同一份状态，通常要上提到共同父层；如果状态只服务局部交互，就应该尽量下沉到更靠近使用位置的组件里，这样更容易控制渲染范围和组件职责。
最稳的回答主线
- 先看状态影响几个组件
- 共享范围大，就上提到共同父层
- 只影响局部交互，就别放到高层制造联动
- 最后补一句：状态位置不仅影响数据流，也影响 rerender 传导范围
面试里容易加分的一句
React 性能优化很多时候不是先上 memo，而是先把状态放到合适的位置，因为状态边界本身就决定了哪些组件会被带动重新执行。
常见追问
- 状态上提是不是越多越好
- 怎么避免为了共享状态把整个页面都提成大父组件
- 本地状态和 Context 的边界怎么划分
最短记忆方式
共享就上提，局部就下沉。