首先我们要知道状态管理工具，他在我们实际项目开发中解决了什么问题，在我们的项目中，是否真的需要它，并不是所有项目中，都需要使用，反而增加项目的复杂度，画蛇添足。

为什么会有状态管理工具？

这种整个应用共享同样的状态，是从这个SPA开始出现的，在没有SPA的世界，我们每次访问一个URL页面都会完全刷新，数据完全来自这个后端直接渲染，所以，根本没有全局状态这个概念，自从SPA诞生之后，前后端分离开始大部分的实现，在不跳转URL的基础上，通过JS渲染界面这种状态管理工具才会不断的出现。

1、单项数据流

微信截图_20210726111802.png

把所有的全局状态都存在根组件中，然后向下传递，然后那里需要，传到那，这个在实际使用当中会遇到一些问题，如果组件有十几级，如果底下某一层组件需要使用到全局组件中的数据某一项，这样就需要通过一层一层的向下传递，但是中间层的组件不需要使用到这个数据，它还是需要通过中间层传递下去，这样会非常麻烦。

缺点

1、多层传递非常繁琐

2、中间传递层有可能根本不需要这个数据

3、根组件压力太大，逻辑代码非常繁琐

微信截图_20210726110959.png

通过一个global.js封装一个全局对象，包含一些数据和方法，当需要使用的时候，直接引入使用，调用当中的数据和方法或则直接修改数据。第一次引入使用貌似没有什么问题，但是如果需要调用当中数据，进行二次修改的话，发现页面并不能更新。

缺点

1、数据非响应式

2、修改无法追踪

3、直接从组建获取数据是一种反模式

状态管理工具开始出现

它们都有一个类似Object的数据类型，但它不同于简单的objec的数据类型，叫store,唯一的真实的数据来源，我们的整个应用全局就一种数据结构来管理，它们的数据不能直接进行随意修改，需要通过调用一个特殊的方法，来实现数据修改，所以它这种设计store中的变化是可追溯的，可以预测的。

微信截图_20210726130221.png 如图，通过store中，调用一个Action方法，进行数据的一个修改，然后通过store实现页面上的更新

状态管理工具的特点：