文章目录
目录导航
快速定位文章内容
正文
React 项目里，我怎么判断状态该放局部、Context，还是 Zustand
React 项目越做越大，最容易失控的往往不是组件数量，而是状态开始到处飘。一个状态如果放得太低，会导致层层透传；放得太高，又会让无关组件跟着重渲染。我的经验是，不要先问“该用什么库”，而是先问“这个状态到底影响谁”。
第一层：默认先放局部状态
如果一个状态只服务当前组件，或者只影响一个很小的局部区域，我会优先用
useState。- 输入框展开与收起
- 当前 tab 切换
- 单个弹窗开关
- 卡片 hover 和 loading 状态
局部状态的好处是边界清楚，读代码时几乎不用跳文件。很多项目的问题，不是局部状态太多，而是本来很局部的东西被过早抽到了全局。
第二层：跨层级共享，但更新频率不高，用 Context
当多个组件都需要同一份数据，而且它们处在同一棵页面树里时，我通常会先考虑 Context。
例如：
- 当前登录用户信息
- 主题模式
- 语言设置
- 页面级筛选条件
这类数据的特点是“很多地方要读，但不是一直在变”。Context 很适合解决传 props 太深的问题，但它不适合承载频繁变化、订阅面又很大的状态。
const ThemeContext = createContext({ theme: 'light', toggleTheme: () => {} })
如果一个 Context 里塞了用户信息、菜单权限、弹窗状态、表单数据和实时计数，那基本就是在给后续维护埋雷。
第三层：跨页面共享、更新频繁，或者需要集中管理，用 Zustand
当状态开始有这些特征时，我会更愿意上 Zustand：
- 多个页面都要用
- 更新频率高
- 需要在非父子组件之间同步
- 想把动作和状态收在一起
比如购物车、复杂筛选面板、全局播放控制、工作台布局偏好，这些都很适合用 Zustand。
const useFilterStore = create((set) => ({ keyword: '', setKeyword: (keyword: string) => set({ keyword }) }))
它的优势不是“更高级”，而是可以让读取方按需订阅，避免所有东西都跟着一个大 Context 一起刷新。
我现在常用的判断顺序
- 先问这个状态是不是只影响当前组件。
- 如果不是，再看它是不是只在当前页面树里共享。
- 如果还不是，再判断它是否值得进入全局 store。
这个顺序能帮我避免两个常见问题：一是把小问题复杂化，二是把全局状态仓库变成垃圾堆。
结语
React 状态管理没有银弹，关键不是站队，而是让状态的作用域和业务影响范围对齐。能放局部就别急着全局，能靠 Context 解决就别先上 store。很多维护成本，都是在“过度设计”和“设计过晚”之间摇出来的。