前端状态管理是很多流行框架统一在做的事，翻开官方文档都有相关的介绍。React框架有Redux，Vue框架有Vuex。但是官方文档并不是万能的解药，依旧没有从本质上解决大家理解这个东西的疑惑。
我习惯将一些复杂的知识点结合Web发展过程总结一些自己的看法，以下是我理解的所谓状态管理，如有偏颇仅代表我个人见解，欢迎吐槽。
我们先假设一个背景，就是以下所有的故事背景都发生在没有电子设备和即时聊天工具的年代。
场景一
我和老王是好朋友，每天下班我们都会坐在公司楼下的酒馆聊天。每天的内容五花八门，后来我们每天都讨论技术相关的东西，不亦乐乎。有天我们聊得内容很多，第二天突然想起有个比较关键的内容，向老王求解，结果他也忘了。后来每次去酒馆都会带上一个本子记下某个关键内容，防止无从查找，而且两个人都能翻阅。
这个场景描述的是Web之前很少有两个以上的页面或者组件发生数据的交互，大家各自记得自己的状态就好，而当两个组件或者页面交互时，通常会采用Storage或者父子组件监听兄弟组件Bus来完成，能实现功能就是当前最优方案。
场景二
后来公司组织技术培训会，一下来了很多人，每个人都准备了很多要说的内容。不光有集中讨论还有小组讨论，大家都积极发言。但是最后要写会议纪要的时候，所有人都懵了，因为谁也不记得谁都说了什么，或者谁补充了谁的技术观点，场面无比的尴尬。
然后大家重新翻开自己和小组的内容记录一条一条的写在了会议室的白板上。关键内容和补充内容一一匹配，花了很长时间，终于搞定了。大家心里不停的骂街，却都无可奈何。
这个场景描述的是，当出现多个组件，或者多个层级的组件进行数据交互时，在多个混乱的操作下，数据状态的修改和更新都没有按照预期的方向发展，也就是组件与组件之间互相维护多个单独数据状态，数据状态的不集中导致多个组件的数据发生混乱。
场景三
再后面每次参加公司的技术讨论会，我们都按顺序在白板上写上对应的内容，有人补充或者反驳都会修改白板上的内容，大家也都能看到。小组讨论出结果也会同步修改白板上的内容，这样随便找个人写会议纪要就可以了，大家终于不骂街了。
后来听说隔壁的两家公司也借鉴了我们的方法，说明我们的方法还是有很多可取之处的。忘了说了我们公司叫Angular，隔壁两家公司一个叫React，另一个叫Vue。我觉得都没有我们公司牛X，我们是第一个想到这个方法的。
通过以上这三个场景，我觉得能让大家直观的看到什么是状态管理。在Angular框架中，所有的状态其实是挂在全局上的，每次更新和修改都是通知全局，然后由全局通知所有用到这个状态的组件。因为是状态集中管理和分发机制，所有组件都没有全部所属权。React和Vue框架都借鉴了这一点，但是是通过一个独立的模块Redux或Vuex来完成。
小结
前端状态管理实际上解决的就是组件通讯以及状态集中管理和分发的问题。不管官方文档如何去描述，核心就是这样。而市面上很多讲解的书籍或者文章也都是官方术语阐述，说实话有的时候太干未必是一件好事。
