我在想你们是不是心里一万句cnm飘过，写那么多做什么？装逼吗？其实不是的，是我在看别人的博客的时候发现一个问题，就是很多人贴代码的时候因为贴的是一部分，导致很多人摸不着头脑，也不知道每一个方法是怎么传递的，我不想我的博客别人看了以后也有这样的疑问，所以才整个直接贴出来，当然我会做出详细的解释，。
解释一下上面的代码：首先我们在页面加载的时候也就是created的阶段将最新的uuid也就是store里面的全局变量的值拿到，有人说你拿到， 为什么还要写下面的，那么问题就来了，如果用户在当前页面直接切换了机器的uuid，那么他没有刷新页面，也没有切换页面，这个时候created是不会执行的，是不是，那么最新的uuid怎么更新呢？你即使监听了但是由于createrd不执行，导致的问题就是你监听的值一直没有变化，所以我们需要将页面里面的uuid变化时刻监听，所以我们需要在computed里面接收最新的uuid，然后我们监听这个里面的值，只要改变，就做出相应的改变，这样就满足了我们的需求，
问题1：为什么使用computed不直接使用watch？
有人看到以后就会觉得我们直接监听这个值不行吗？我们这里要明白的是watch是只可以监听data里面声明的变量或者对象，除此之外是监听不到的，而computed用来监控自己定义的变量，该变量不在data里面声明，直接在computed里面定义，然后就可以在页面上进行双向数据绑定展示出结果或者用作其他处理。
问题2：为什么使用缓存？
这里使用缓存的目的是为了你第一次进来的时候，如果用户什么都不切换，不执行change_machine函数的话，那么我们请求接口的参数是空的，所以我们需要默认一个值，你可以直接在store里面默认，也可以我在第一次进来的时候直接判断是不是存在store的值，没有的话就用我默认的缓存里面的值。
问题3: 为什么created里面已经拿到了，还要写监听函数？
这个问题可能有人会问，但是其实很简单，因为用户不刷新页面的时候created是不执行的，那么我们就拿不到最新的uuid进行数据的更新，所以要写监听的函数。
问题4: 为什么使用this.$store.dispatch？
我们这里使用是根据官方文档来的，你可以直接使用commit或者什么也不用，直接this.$store.state.machine_uuid_flag也是可以的，但是我们改变了uuid，那么就要重置一下store里面的原始值，所以这里需要接收我们改变的值，也就是用户选择了别的机器的时候用的值。如果我们不需要重置原始值的话，可以直接定义一个全局变量，然后直接
this.$store.state.machine_uuid_flag(这里格式乱了)就可以了，但是这样的业务场景应该不多。毕竟我们定义了就是为了改变它从而我们可以监听这个变化的值。
总结
写到这里基本上的用法我写完了，可能写的没有那些大神写的详细，也没有什么原理分析，写的也比较浅显，我看很多人写博客的时候喜欢分析一下原理，一方面显的专业性比较高，一方面可以有利于自己的理解和别人的理解，首先我也是不经常使用这个技术栈，其次是我个人觉得用的好要比明白原理强，我不喜欢只讲原理一个例子都不写的人，毕竟例子是最可以发现问题的，也是最直观的，就写到这里吧，以后再更新，我写博客的目的是记录自己写项目的过程，记录用到的东西，以后用到了更深的再更新，希望可以帮助到人更好。写的不对的希望可以直接联系我，我及时纠正，谢谢大家的支持。