关于 在vue项目中的一次 性能调优

项目场景：

还是上篇文章提到的项目，前不久本地测试无异常，现在已经在线上运行了，但是好日子（摸鱼）没过多久，
后端就找上门了…

后端：现在线上由于并发请求太多了，要是有那么一两个请求响应慢了一点的话，非常容易超时然后挂掉。
理想的我：请求响应慢也找我，真当我前端好欺负？
真实的我：行吧大哥，那我这边控制一下同时请求的次数，做一个分批次请求，你看这样行不？

后端：这还差不多，别一次性给我那么多请求，我处理不过来，我不想改代码
理想的我：我X你XX的，你不想改就丢给我，才13个请求就整不动了？想想双11人家的后端要处理那么多高并发，你TM菜的抠脚
真实的我：好嘞，我看了一下，谷歌最高支持6个并发请求，那我就分三组吧，每组4个请求，你看可以不

后端：行吧，先这样吧，快点啊，项目着急上呢，慢了到时候又是你的锅，懂？
理想的我：我TM遇上你这个吊毛，算我倒霉，先让你嚣张吧，老子明天就离职跑路，你个栽种。
真实的我：行嘞，咱前端是啥呀，不就是背锅的么，你放心瞧好吧，不管最后咋样，锅只管给我背上就行！

问题描述：

同上，可以看出，后端给了13个接口，每个接口都是独立的，没有任何数据关联，直接同时发出请求，
然后取出各自的数据展示即可，

别问我为啥要给我13个接口，我啥也不知道，我啥也不想说

问题1：子组件过多，如何控制组件请求的先后顺序

问题2：就算能控制每个组件执行的先后顺序，但是每个组件里面的axios请求又如何控制先后呢？

【一眼看下来，其实本篇文章的核心就是处理问题1和问题2】

原因分析：

其实造成 问题1的原因很矛盾，很纠结，以至于到现在写这篇文章的时候，我也没有想到一个好的优化方式
什么原因呢？
其实，就是组件拆分过多引起的，如果我不拆组件，页面就一个大的组件展示，那我可以很优雅的处理掉问题1，
因为，在一个组件里面完成所有的请求，哪还有什么组件执行先后的破事啊，问题1直接跳过了好吧
但是，拆了就拆了吧，至少组件化以后，代码量明显减少了，而且改的时候只需要找到对应的组件就行了

所以，凡事有利有弊，我享受了组件化拆分带来的利，就不得不面对组件通信带来的弊。

造成问题2的原因，U1S1，是我最开始没考虑周全，从没想过 要处理异步执行先后的问题
只想着在每个组件的created里面依次请求就行了，因为在本地测试的时候，一点问题都没有，后端那边的响应，
也是非常快的，都在ms以内就响应了，

现在想想，确实不应该那样做，一股脑地请求，想想都觉得可怕。

【这次也算是 做了一次 前端性能调优吧，哈哈】

解决方案：

解决问题2（优先）：

在网上溜达一圈以后，收集了几种处理这个问题的办法

1. ES6 Promise 链式写法，调用请求
2. async/await 语法糖 + Promise 联合改造请求方式
   3. 最原始的方法，回调嵌套，（现在没人会这样做，因为一点也不优雅）

关于Promise不用多说，天生就是来处理这个问题的：

Promise 是异步编程的一种解决方案，比传统的解决方案——回调函数和事件——更合理和更强大。它由社区最早提出和实现，ES6 将其写进了语言标准，统一了用法，原生提供了Promise对象。
所谓Promise，简单说就是一个容器，里面保存着某个未来才会结束的事件（通常是一个异步操作）的结果。从语法上说，Promise 是一个对象，从它可以获取异步操作的消息。Promise 提供统一的 API，各种异步操作都可以用同样的方法进行处理。

再放上一个权威链接，欢迎有缘人进入学习
Promise对象-ES6 入门

方案一: