一、这个技术是什么？

当一个页面只有一个按钮时，状态可以放在按钮组件里；当筛选条件要影响列表、URL 和统计面板时，状态就需要被放到合适的共享位置。

状态管理解决的是“谁拥有数据、谁可以修改数据、其他组件如何得到变化”的问题。

二、没有它之前发生了什么？

状态散落在多个组件
↓
组件之间互相传值，出现多层 Props
↓
为了省事把所有状态放进一个全局对象
↓
任何更新都可能影响整棵组件树
↓
根据状态影响范围选择通信方式

三、核心概念

1. Local State

只影响一个组件或局部区域的数据，优先放在最近的拥有者组件中。

2. Lifting State Up

多个兄弟组件需要同一份数据时，把状态提升到共同父组件。

3. Context

Context 适合主题、语言、用户等较稳定的跨层数据，但不应该成为所有状态的垃圾桶。

4. URL State

搜索词、分页和筛选条件适合放进 URL，因为它们需要分享、刷新后保留或支持浏览器前进后退。

5. External Store

跨页面、复杂更新或需要独立订阅时，可以选择外部 Store，但应先确认 Props、Context 和 URL 是否已经足够。

四、运行流程

五、面试复习

一句话回答

状态管理的关键不是选择某个库，而是确定状态的拥有者、影响范围和更新边界，再选择 Local State、Props、Context、URL 或 Store。

高频追问

• 什么情况下需要 Redux 或其他 Store？
• 为什么筛选条件适合放在 URL？
• Context 能不能替代所有状态管理？
• 如何减少状态更新带来的重复渲染？

容易答错

不要把“全局状态”理解成“所有数据都放全局”。全局范围越大，依赖关系和更新成本通常越高。

六、项目展示

知识平台可以把搜索词放进 URL，把收藏状态放在客户端 Store，把 Markdown 知识作为服务端数据。三类状态职责清晰，便于后续增加登录和同步。