这是一种比较奇葩的算法，也就是说，OK和3秒同时具备的话，resolve为2，则让按钮可点，只错误的话，resolve会等于或大于2，就立即让按钮可点，同时报错。
如果ajax超时，比如断网了，那么也会返回错误，只不过这个错误可能会10秒/20秒/30秒/60秒之后返回（根据你的ajax配置），其实这也属于上面说的ajax返回错误，所以依然是适用的。
情况3：点击之后跳转页面
点击之后跳转页面也很常见，无奈跳转页面也是需要时间的，也可以多次提交。怎么办？
页面打开时，让按钮可点（跟对话框场景道理一样）
点击之后验证，通过则立即不可点，不通过则不针对按钮处理
通过之后，当ajax返回OK，则立即跳转（不去恢复成可点），这样鼠标重复点击多少次都没事。当ajax返回错误，则弹出错误，且按钮恢复为可点
为什么当ajax返回错误后不防范重复点击？
因为我们将普通用户定义为：非常喜欢点击鼠标，但思维正常的人，既然用户已经看到了提示错误，当然就不会再重复点击了，况且错误提示往往会是MessageBox，它会阻止重复提交。我们更多的是考虑如何防范鼠标连击的情况。
恶意重复提交
前端永远是防君子，难防小人的，恶意攻击者想要恶意重复提交的话，一定会直接攻击后端，所以上面所有措施一律无效，还需要后端做措施，这里就不多说了。
最后说说axios拦截提交
根据网上一些教程，axios拦截提交其实是有问题的：
它的拦截，其实是在重复提交的时候拦截前一次的提交，而我们通常认为，应该拦截后面发生的所有提交。
ajax速度有时候非常快，根本来不及拦截。
api写的太晦涩了。
需要考虑多种情况，比如有的时候允许3秒提交一次，有的时候随时可以提交，拦截规则越搞越复杂。
利用URL和params特征判断是否能解决问题
比如，规定时间内（比如3秒），或者不设规定时间，只要向同一个URL发送同样的数据，就禁止发送。表面上看起来，似乎防范重复提交的本质就是要阻止同样的数据重复发送，但是这里面依然有问题。
比如规定时间3秒内不能发送同样数据，那么，如果是axios全局做判断，就要考虑，会不会有其他的ajax穿插在3秒里面，所以说，每次准备ajax发送请求，就要遍历追溯前三秒发送过的请求里有没有重复请求，所以始终要记录每一次请求，还要记下时间戳，似乎有些麻烦。如果只是根据每个提交事件做统计，其实道理一样，也是要遍历。
而且，如果用户每隔4秒点击一次，而ajax返回用时5秒，那么第二次请求就真的会发出去。
如果不规定时间，只要发送同样数据就一定拒绝，那么，如果用户不经意间，在3分钟内2次提交了相同的内容，允许不允许提交呢？比如用户3分钟中了2次奖，填了2次个人信息，允许提交吗？按说应该允许，因为有些场合确实可能存在用户提交同样内容，但是，现在禁止提交，就阻截了正常提交。最后只能是把拦截规则越搞越复杂。
当然，最为致命的问题是：用户体验莫名其妙。无论什么技术，都要把用户体验放在第一位，如果开发者不去管按钮能否点击，只做背后的拦截逻辑，也就是始终让按钮能点击，用户毫无疑问会有很大概率多次点击，如果赶上ajax慢，用户会疯狂点击，最后疯掉也不夸张，这不是我们想要的结果。
所以说前端拦截重复提交的最好办法一定是用正确逻辑控制按钮的disabled。