把React当银弹五年后，我开始劝退盲目上状态管理的人

五年前，如果有人问我前端选型，我会毫不犹豫地说：React，配上 Redux 或者 MobX，一套组合拳打天下。那时候的我，把 React 当成银弹，把状态管理当成银弹的弹夹——没有状态管理的 React 项目，在我眼里就像没上锁的保险柜，迟早要出事。五年过去了，我经手的项目从初创产品到千万级日活的中台系统，踩过的坑比写过的组件还多。现在，当团队里新来的同学兴奋地提议“咱们上 Zustand 吧，或者 Recoil 也行”时，我第一反应往往是：先等等，你确定你需要状态管理吗？

这不是反智，也不是技术保守。恰恰相反，我依然认为 React 是构建复杂 UI 的优秀工具，状态管理在特定场景下也是刚需。但问题在于，过去五年里，状态管理被过度神化了。它从一种解决特定问题的方案，变成了一种政治正确——仿佛不用状态管理，代码就不够“工程化”，架构就不够“可扩展”。这种思维惯性，让很多团队在项目还没搞清楚业务边界的时候，就先背上了一套状态管理框架的认知负担。

先说说我为什么曾经把 React 当银弹。2018 年前后，前端圈的主流叙事是“组件化 + 单向数据流”。React 的声明式渲染和虚拟 DOM 确实让 UI 开发变得可预测，但组件之间的通信很快成了痛点。props 层层传递的“钻取地狱”让代码难以维护，于是 Redux 带着“单一数据源”和“纯函数 reducer”的理念登场，一时间成了 React 生态的标配。那时候的我，逢人便说：状态管理是 React 应用架构的基石。现在回头看，这种论断忽略了两个关键事实：第一，大多数应用的跨组件状态并没有想象中那么多；第二，React 自身在进化，Context API 和 hooks 已经能覆盖相当一部分场景。

转折点发生在 2021 年前后。我负责一个内部工具平台的重构，团队决定用 Redux Toolkit 统一管理所有状态——包括表单输入、弹窗开关、甚至 hover 效果。结果呢？一个简单的下拉选择框，要经过 action、reducer、selector 三层才能拿到值。开发效率不升反降，新人上手成本陡增。更讽刺的是，后来我们发现，80% 的所谓“全局状态”其实只在两个组件之间共享，用 useState 提升到父组件就能解决。那次重构让我开始反思：状态管理的边界到底在哪里？

如今的前端生态已经和五年前大不相同。React 18 的并发特性、Server Components 的兴起，都在重新定义“状态”的归属。很多状态天然属于服务端，比如用户信息、列表数据，用 React Query 或 SWR 这类数据获取库处理，比塞进全局 store 更合理。而客户端状态，比如 UI 的展开收起、表单的临时输入，用 useState 或 useReducer 配合 Context 往往就够了。盲目上状态管理，反而会把简单问题复杂化。我见过太多项目，在还没搞清楚哪些状态需要全局共享之前，就先引入了 Redux 或 Zustand，结果 store 里塞满了本不该存在的“全局状态”，最终演变成一锅粥。

当然，我不是全盘否定状态管理。对于大型复杂应用，尤其是需要时间旅行调试、状态持久化、或者多端共享状态的场景，成熟的状态管理方案依然有价值。但关键在于“按需引入”。我的建议是：先用 React 自带的工具解决问题，当遇到明确的痛点——比如跨层级通信频繁、状态逻辑复杂到难以追踪、或者需要与外部系统同步状态——再考虑引入轻量级的状态管理库。而且，选型时要关注库的哲学是否与团队匹配。Zustand 的极简、Jotai 的原子化、Valtio 的代理模式，各有适用场景，没有银弹。

更深层的问题是，很多团队把状态管理当成了架构设计的替代品。他们以为引入一个状态管理库，就自动获得了良好的架构。实际上，状态管理的核心不是库，而是对状态边界的清晰划分。哪些状态是局部的，哪些是共享的，哪些是派生出来的，这些问题的答案决定了代码的可维护性，而不是你用了 Redux 还是 MobX。我见过用 Redux 写得一团糟的项目，也见过只用 useState 和 Context 就组织得井井有条的大型应用。工具是次要的，思考才是主要的。

最近我在 review 一个新项目的代码，发现团队用了 Zustand 管理一个模态框的显示状态。我问为什么不用 useState，回答是“方便以后扩展”。这种“为未来可能的需求提前买单”的思维，正是盲目上状态管理的典型症状。软件开发的不确定性已经够多了，我们没必要在状态管理上再增加一层不必要的抽象。YAGNI 原则在这里同样适用：你不会需要它，直到你真的需要它。

所以，当我劝退盲目上状态管理的人时，我劝退的不是状态管理本身，而是那种“不用状态管理就不够专业”的思维定式。React 不是银弹，状态管理也不是。真正的银弹，是对业务边界的深刻理解，是对状态生命周期的清晰把握，是愿意用最简单的方案解决问题的克制。五年后的今天，我更愿意把状态管理看作工具箱里的一把扳手，而不是必须挂在墙上的装饰品。用不用它，取决于你要拧的螺丝有多大，而不是别人墙上挂了什么。