vue详解
Vuex教程第一讲：Vuex 到底是什么？
先说两句
官方已经有教程了，为什么还要写这个教程呢？说实话，还真不是我闲着蛋疼，官方的教程真的是太官方了，对于刚入门 Vuex 的童鞋来说，想必看官方的教程，很多地方就如同看圣经一样，比如「欧玛尼玛尼牙」，所有的字都认识，就是不知道说些什么玩意，不信，你可以戳进去看看。
当然，对于大神级别一看就懂的，那就不用说了，肯定是看官方的更权威。还有，如果对 Flux、Redux、The Elm Architecture 比较熟悉的话，也可以移步官方，因为官方也说了，Vuex 的套路基本上都是从那边吸取整合后，过渡而来的，只不过，Vuex 只钟情于 Vue.js 罢了。
我之所以写这个教程，主要是因为自己刚刚开始和 Vuex 打交道的时候，痛过了、苦过了、伤过了，所以痛定思痛，为了能让自己更好的驾驭 Vuex，也为了不让新来的童鞋们被 Vuex 调戏过后无处诉苦，所以方才决定把官方的这些抽象的文字和概念，用连你身后的鼓励师小姐姐都能看懂的语言，分享出来，助你在前端的道路上越走越顺，顺利的找到一份有鼓励师陪伴的工作。
再说一句
Vuex 是 Vue.js 的座驾，所以，如果还不懂 Vue.js 的话，那还是先把 Vue.js 勾搭上了再带过来一起坐坐吧。当然，既然能够溜达到这里，想必跟 Vue.js 起码也已经是朋友了吧。
有点啰嗦，不要嫌弃，写教程也需要有点前戏，毕竟是第一次。
安装
关于 Vuex 的具体安装，就不在这里说了，这个官方还是比较清晰的，戳此进入。但是需要注意两点：
在一个模块化的打包系统中，您必须显式地通过 Vue.use() 来安装 Vuex，比如：
当使用全局 script 标签引用 Vuex 时，就不用那么麻烦了，直接引用进来就好，但要注意引用的先后顺序，如下：
虽然 script 的方式看起来比较自动化，但是接触得多了，你就会明白模块化其实才是我们的最佳姿势。
揭开 Vuex 的神秘面纱
拿到一个工具，我们第一时间需要弄明白的，就是这个工具到底能够帮助我们解决什么问题。比如锤子，砸得了鸡蛋打得了电话，比如苹果，不但能吃还能玩。那么 Vuex 呢，如果把 Vue.js 比喻成路人（走路的人）的话，那么 Vuex 就是他的桑塔纳，如果他想去隔壁买包烟，那走过去就行了，开个车过去反而是一种负担，但是如果他想去几十公里的学校采花，那桑塔纳就得派上用场了，不然等他走过去，可能花儿都谢了。
当然，类比只是为了告诉我们 Vuex 的价值所在，那么在具体在实际的应用中，它能干什么？什么时候才需要翻它的牌呢？
我们先来看一段官方代码：
这是一个很简单的增长型计数功能页面，和 Vue.js 有一腿的，应该秒懂。通过事件 increment，实现 count 增长，然后渲染到界面上去。
这种方式其实就跟走路买烟一样，属于短途效应，官方称作为「单向数据流」，很好理解。
但是，情况变了，现在有两个页面 A 和 B，还有以下两个要求：
1.要求它们都能对 count 进行操控。
2.要求 A 修改了 count 后，B 要第一时间知道，B 修改后，A 也要第一时间知道。
怎么办？稍微有点开发经验的，就能够很容易的想到，把数据源 count 剥离开来，用一个全局变量或者全局单例的模式进行管理，这样不就在任何页面都可以很容易的取到这个状态了。
是啊，这尼玛就是 Vuex 背后的思想啊，它干的就是这个事情。是不是有一种被 Vuex 这个高大上的名号所坑害的感觉，不就是全局模型吗，不用它也同样可能搞定嘛。
是的，也可以搞定，就像没有桑塔纳，你也可以去学校看花一样，只是经历的过程不一样了。
Vuex 的目的是为了管理共享状态，为了达到这个目的，它制定了一系列的规则，比如修改数据源 state、触发 actions 等等，都需要遵循它的规则，以此来达到让项目结构更加清晰且易于维护的目的。
那么我们再来看看官方的描述：
有没有瞬间清晰多了。
什么时候翻 Vuex 的牌
其实了解了 Vuex 要干的活以后，什么时候翻牌，那就容易选择得多了。就像前面的类比一样，去隔壁买包烟，你还开个桑塔纳，找停车位的时间，烟都抽完了。
所以，我们要根据项目的需要，来衡量短期和长期的效益，如果不打算开发大型的单页应用，那 Vuex 可能还是你的一个负担。对于一些不大不小的项目，自己又懒得走，开车又觉得麻烦，那你骑个共享单车过去也行嘛。
这里的共享单车指代的是官方中的一个简单的 store 模式，其实就是一个单纯的全局对象。
关于全局对象和 Vuex 之间的区别，官方写得还是比较通俗易懂的：
简单示例
注意：如果 mutations 不知道是什么，没关系，后面会专门讲解到，可以单纯的理解为只能用它里面的方法来修改 state 中的数据。
为什么要这样设计的，官方也给出了具体的原因：
