star超火名目 23k 恳求提升写的一塌懵懂！我间接重构！
敞开重复恳求
敞开重复恳求是一个前端名目中很经常出现的网络恳求提升手腕，他重要是为了防止短期间内发送了多个如出一辙的恳求，造成性能的消耗~
23k star 的名目是怎样做的？
github 上有一个很火的名目，叫做Vben-Admin，是一个十分杰出的后盾治理系统模板，但是团体感觉它的敞开重复恳求做的一塌懵懂（上方会说理由）！！！
由于名目中源代码比拟多，我尽量简化了代码，给大家展现一下它是怎样去成功这个配置的
我先说一下它成功这个配置的思绪：
简化后的代码如下
接着在页面中经常使用
假设我点击了三次，那么它会将我前面的两次敞开掉，只让第三次恳求成功，从而成功敞开重复恳求的配置~
但是这个打算缺点真的很大，比如看上方的例子，我不止一个按钮调用了，我有两个按钮去调用这个接口
我先点击了按钮1，再点击按钮2，发现它把我按钮1的恳求敞开掉了，只恳求了按钮2的恳求，其实这是没错的，但是错就错在，它敞开了按钮1的恳求，但是连着按钮1点击事情接上去的代码都终止掉了！！！！
可以发现，控制台没有打印按钮1的结果，只打印了按钮2的结果！！！
这显然是不正当的，咱们敞开重复恳求只是为了缩小网络资源、性能的消耗，但是可不想由于这个提升，而影响了咱们原本的逻辑~
其实上方的按钮1、按钮2，也可以类比为页面1、页面2，两个页面在短期间内动员了同一个恳求，你间接去把页面1的后续逻辑都终止了，这不是一个好的打算！！！
并且其实不正当的中央还有：Method + Url当做 key，确实不太正当（但是本文暂且不关注这点）
自己思索怎样做~
想了一下，不能用上述的打算来做，缺点太大了，自己想的模式就是不敞开恳求了！而是间接不发恳求！大略的思绪如下：
简化后的代码如下：
结果如下，按钮1、按钮2各自的后续逻辑会继续启动
且恳求只会收回一次性
第一个恳求报错了咋办？
我这个打算是以第一个恳求为主的，那么，假设第一个恳求失败了，那后续的重复恳求就爷跟着失败吗？显然是不对的~
第一个恳求失败之后，咱们必定让后续的恳求再从新走一次性流程才对，就像是一切都没出现过一样！
只要要在后续重复恳求的失误回调中，从新口头恳求即可，这样又能从新来过了！！！
可以看到，就算前面的失败了，前面的照样能自己动员恳求启动自救
有完善的空间
以上只是我依据自己思绪写出的一个粗略版本，假设大家有自己其余的顾忌，可以启动修正精进！
