北京
周三下午三点，办公室又吵起来了。一位前端兄弟把需求评审会变成了状态管理辩论赛：“直接用 Context 啊，这还要讨论？”“Redux 才是标准方案！”“Zustand 不香吗？”项目代码还没写一行，工具先选了三小时。我打开购物车需求——一个导航栏上的图标要显示商品数量，侧边栏要能删改，产品卡片里有个“加入购物车”按钮。
他们把问题想复杂了。产品卡片上的“加入购物车”按钮，点击后短暂显示“已添加！”，1.5 秒后消失。这段交互只需要一个布尔值：justAdded。它只活在 ProductCard 组件内部，兄弟组件 CartSidebar 不知道，祖辈 App 不关心，页面切换后重置也没人在意。这就是 useState 的教科书场景。但会议上没人提它——因为 useState 不够“厉害”，不值得争论。
这恰恰是大多数团队踩坑的起点：不先定义“状态属于谁”，就急着上全局方案。我见过一个表格组件的分页页码被塞进 Redux，就因为后端同事说“状态要集中管理”。还见过用来控制弹窗开关的 boolean，跟着 Context 一路传了五层 props。这些都不是架构问题，是忘了 React 原本的哲学。
useState 设计之初就划好了边界：它只管一个组件自己的事。满足三个条件时，它就是你唯一需要的工具：
- 这段状态不被其它组件读取；
- 不要求跨页面存留；
- 不与兄弟节点或远祖组件联动。
购物车的例子很诚实。ProductCard 里 justAdded 这个值，正是典型“暂时、私有且不需要外传”的状态。它独立完成反馈动画，不污染父级，不拖累渲染，1.5 秒后自动复位。换成 Context？为了一个按钮的视觉效果，你要先创建 Provider，再在消费端写 useContext，还要考虑重新渲染的范围。换成 Redux？你得写 action、reducer，再 dispatch，然后盯着控制台看有没有多余订阅。这已经不是杀鸡用牛刀，是拿着牛刀去切豆腐——豆腐碎了，手也酸了。
争论工具前，先去画组件树。问问自己：这个状态究竟是“全局的”，还是“某个组件的私事”？如果答案模糊，那就先用 useState。等 props 真正钻到第三层、第五层，等两个不相干的子树真的需要同一份数据时，再对照你的问题去挑 Context、Zustand 或者 Redux。那时你手里有具体的痛点，而不是道听途说的“这个库很流行”。
下次再有人把技术选型聊成信仰之争，你可以把产品卡片的按钮效果打开，问他：“这个状态，你想用哪种姿势管理？”十有八九，他会闭嘴。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
