前端技术演化史

状态管理演进史

Properties1
tags状态管理, flux, redux, mobx, pinia, zustand

7分钟阅读

🗃️ 状态管理演进史

一句话定性

组件化解决了”UI 复用”,却制造了一个新难题:多个组件要共享同一份状态,数据怎么流动才不乱? 整部状态管理史,是一只在两极之间摆动的钟摆:可预测性(显式、约束、样板) ⇄ 开发效率(隐式、自由、极简)。

一、它是什么 & 出现的时代

“状态管理”指:在组件化应用里,管理跨组件共享的数据(状态)如何被读取和修改的机制。

它诞生于 2013-2018 SPA时代。当 React/Vue 把 UI 拆成成百上千个组件后,一个尖锐的问题浮现:用户登录信息、购物车、主题——这些被很多组件用到的状态,放在哪、谁能改、怎么通知所有用到它的组件更新?

            App
           /   \
       Header   Main
        /         \
   购物车图标      商品列表(点"加入购物车")
        ▲              │
        └──── 状态在哪里共享? ───┘
          (props 层层透传是噩梦)

二、为什么会出现(解决上一代什么痛点)

组件化带来的状态困境

  1. Props 透传地狱(prop drilling):深层组件要用的状态,得从顶层一层层往下传,中间组件被迫当”二传手”。
  2. 兄弟组件通信难:两个不相干位置的组件要共享状态,只能把状态提到共同祖先,结构被扭曲。
  3. 状态变化难以追踪:谁、在什么时候、为什么改了这个值?数据流一乱,bug 无从下手。

核心矛盾:当状态被很多组件共享、又能被很多地方修改时,“数据流动”本身就需要一套架构来约束。 这正是 Flux / Redux 要解决的问题。

三、核心机制 & 为什么流行(钟摆的两极)

整个发展史就是一场**“可预测性 vs 样板代码”**的钟摆运动:

    可预测性高               钟摆               开发效率高
    样板代码多                                  样板代码少
    ◄───────────────────────●───────────────────────►

  Flux/Redux            Vuex/Pinia            MobX / Zustand
  (严格单向数据流)      (Vue 生态折中)         (响应式 / 极简主义)
方案年份阵营哲学一句话
Flux2014Facebook单向数据流架构(只是思想,非库)提出”数据只能朝一个方向流”
Redux2015React单一数据源 + 纯函数 + 不可变极致可预测,但样板被诟病
MobX2015通用/React透明响应式 + 可变状态反样板,改值即更新
Vuex2015Vuemutation/action(Redux 思想 + 响应式)Vue 官方答案(已让位)
Pinia2019→VueComposition API 风格,去 mutationVue 3 官方推荐,取代 Vuex
Zustand2019→React无 Provider、hooks、极简对 Redux 样板的彻底反叛

四、带来的新问题 / 副作用

每一极都有它的代价

  • Redux 一极的代价:可预测性是用样板代码换的——“改一个值要写 action + reducer + dispatch 三处”,被群嘲”为了改个值要写三个文件”。
  • MobX 一极的代价:响应式的”魔法”省了样板,但数据怎么变的不透明,debug 时难追踪;可变状态也违背函数式直觉。
  • 过度工程化:很多小应用根本不需要全局状态库,却跟风上 Redux,徒增复杂度(违背奥卡姆剃刀)。

没有一极是终极答案——钟摆的存在本身,说明这是个权衡问题,不是对错问题。

五、现状 / 演化

钟摆并未停止,但近年明显朝”极简 + 响应式”一侧倾斜:

  • Redux 用 Redux Toolkit(RTK) 自我救赎,大幅削减样板,仍是大型企业级首选。
  • Zustand(Poimandres 出品)在 React 社区迅速流行,代表”够用就好”的极简潮流。
  • Pinia 成为 Vue 3 官方推荐,Vuex 退役。
  • Jotai / Recoil / Valtio 等”原子化 / 代理响应式”新流派涌现。
  • 同时,React 自带能力增强(Context、useReducer、未来的 RSC + Server Actions 把部分状态移回服务端),让”是否还需要状态库”本身成了新问题。

六、对后续技术的影响(因果链)

 组件化 ──► 跨组件状态共享难题(prop drilling / 兄弟通信)
                       │
                       ▼
                Flux 架构(2014,单向数据流思想)
                       │
        ┌──────────────┼─────────────────────────────┐
        ▼              ▼                              ▼
   [[Redux]](2015)   [[MobX]](2015)              Vue 生态自走一路
   单向/不可变/可预测   响应式/可变/反样板             [[Vuex-Pinia\|Vuex]](2015)
        │              │                              │
        │ 样板太多      │ 透明但难追踪                  │ Vue 3 + Composition API
        ▼              │                              ▼
   Redux Toolkit       │                          [[Vuex-Pinia\|Pinia]] 取代 Vuex
   (削减样板,自救)     │                          (去 mutation,更简洁)
        │              │
        └──────┬───────┘
               ▼
   钟摆摆向"极简" ──► [[Zustand]](无 Provider、hooks、极简)
                       │
                       ▼
   + [[React]] Context / RSC / Server Actions ──► "还需要状态库吗?"的再追问

历史地位

状态管理史是前端架构思想成熟的缩影:它从 Redux 的”用约束换可预测”出发,被 MobX 的”用响应式换效率”反驳,在 Vuex-Pinia 找到框架内的平衡,最终被 Zustand 拉回极简。这条线没有终点,因为它的本质——可预测性与开发效率的权衡——是软件工程的永恒张力。理解这只钟摆,就理解了”为什么没有一个状态库能一统天下”。

🔗 相关:Redux | MobX | Vuex-Pinia | Zustand | React | Vue | 2013-2018 SPA时代

关系图谱

反向链接