状态管理 2026：Zustand、Jotai 与 Signals 之争

状态管理曾经是前端最热闹的战场，Redux、MobX、Recoil 轮番登场。到 2026 年，喧嚣退去，方案趋于收敛。本文谈谈当下的主流选择与判断标准。

先回答一个问题：状态从哪来

很多争论源于把两类状态混为一谈：

• 服务端状态：来自 API 的数据，有「加载中/成功/失败」的生命周期，需要缓存与重新获取；
• 客户端状态：UI 交互产生的临时状态，如弹窗开关、表单草稿、主题。

这两类状态的性质完全不同，用同一套工具硬套往往是痛苦的根源。

服务端状态：交给数据层

对于服务端状态，专用数据请求库是更优解。React Query、SWR、Apollo 这类工具帮你处理缓存、去重、失效与后台重新获取，把「数据」从组件里解放出来。

它们与状态管理库并不冲突，而是各管一段：数据层管服务端状态，状态库只管真正需要全局共享的客户端状态。

客户端状态：轻量化的胜利

当数据层接管了服务端状态后，剩下的客户端状态往往很少，于是轻量方案崛起：

• Zustand：极简的 store API，无样板代码，兼容性好；
• Jotai：原子化（atom）模型，细粒度订阅，适合派生状态；
• Signals：以「响应式信号」为核心，性能极致，在部分框架生态中流行。

我的选择标准

1. 先减少状态：能用派生就不存，能局部就不全局；
2. 服务端状态用数据层，不要塞进全局 store；
3. 客户端全局状态才用 Zustand 这类轻量库；
4. 避免「为用而用」——很多场景 useState + useContext 已足够。

结语

状态管理的最高境界是「没有多少状态需要管理」。把状态分类、把职责划清，比追逐最新最热的库更重要。