很多前端同学第一次接触状态管理时，往往先记住一串工具名：Redux、Vuex、Pinia、Zustand。
但如果只背工具，很容易越学越乱。因为真正应该先搞懂的，不是“该选哪个库”，而是“这些库到底在解决什么问题”。
答案大多可以追溯到一个老名字：Flux。
2014 年，Facebook 提出了 Flux。它不是框架，也不是你直接拿来装进项目里的 npm 包，而是一种前端应用架构思想。
它的核心很简单：
如果把 UI 抽象一点，它理想中的样子就是：
ui = f(state)
也就是说，界面尽量像一个纯函数。给它什么状态，它就渲染出什么结果。
设想一个熟悉的场景：微信右上角那个未读消息小红点。
它会因为很多地方变化：
这些变更来自多个模块。如果每个模块都能直接修改“小红点数字”，代码很快就会变成一团互相牵扯的线。你改聊天模块，通知模块可能跟着出问题；你修复一个角落，另一个地方又冒出副作用。
Flux 提供的思路是：别让模块直接乱改状态。
大家都只负责“提出变更请求”，真正怎么更新，由统一的状态仓库来处理。这样一来，数据流是单向的，变更路径是可追踪的，问题也更容易定位。
很多人把状态管理理解成“全局变量高级版”，这有点低估它了。
状态管理真正要解决的，是项目规模一上来之后的复杂度：
换句话说，当状态开始跨组件、跨模块流动时，你就需要一套规则，而不是只靠开发者自觉。
这也是为什么早期最有代表性的状态管理工具，看起来都带着 Flux 的影子。
Redux 可以说是 Flux 思想最典型的一次极致化实现。它强调单一状态树、纯 reducer、显式 action，把“状态如何变化”写得非常清楚。代价就是样板代码偏多，但回报是可预测性极强。
Vuex 虽然长在 Vue 生态里，但本质上也延续了类似思路：集中管理状态，通过约定好的方式修改状态，让页面渲染和状态流转分开。
它们名字里那个常被调侃的 “x”，某种意义上也确实是在向 Flux 的血统致意。
再往后，社区开始反思一件事：Flux 的思想很好，但很多实现是不是太重了？
于是新一代工具开始出现：
这些工具表面上变轻了，但本质并没有背叛 Flux。
它们依然在做同一件事：
所以你看到的是 API 变化，底层逻辑却很稳定。
很多人会觉得，现在都 AI 编程了，还需要啃这些“老概念”吗？
恰恰更需要。
因为 AI 最擅长的是局部生成，不是天然擅长长期维护。当一个项目没有清晰的数据流和边界，AI 很容易把逻辑不断堆进组件、页面和回调里，最后生成一堆“能运行但难收拾”的代码。
而状态管理思想，本质上是在帮我们回答几个非常关键的问题：
这不只是为了让人读代码更轻松，也是为了让 AI 更不容易把工程结构写崩。
从 Flux 到 Redux、Vuex，再到 Pinia、Zustand，表面看是工具更替，实际看是同一个问题在被不断重新回答：
当前端应用越来越复杂时，我们怎样让状态变化仍然可理解、可追踪、可维护？
只要这个问题还存在，Flux 的思想就不会过时。
你可以不用 Redux，也可以不用 Vuex，但最好知道自己为什么需要，或者不需要，一套状态管理方案。