逻辑场景： 业务组件内部正常使用的table来展示一组list数据，照例使用了饿了么的分页组件，
bug复现：正常操作是没啥问题的， 测试妹子来了个骚操作，1.将pagesize调为最小，2. 然后跳转到最后一页，3.将pagesize调大，
原因分析： 本来也没啥， 不就是触发了两次getlist请求而已，因为你手动改了pagesize 触发了一次pagesizeChange进行了一次，因为pagesize改变，而total未变，导致了组件内部从新计算了page。所以你的最后一页也被组件强制改动了，触发了 pageChange,又进行了一次， 而这两个函数一般内部都是进行的从新获取数据的异步操作，这样就出现了一个问题，如果pagesizeChange率先完成，此时因为你传的pagesize * currentpage的积是超过total的， 所以后台必然是给你反的是一个空数组， 这时候pageChange再返回，入参时组件帮你计算的最后一页的页码和你选择的pagesize,是可以正常获取数据的， 只是后台走了两次接口， 如果你页面上的table没有进行v-if判断来决定显示的话也是没问题的，但是队友好死不死的偏偏拿返回数据list的长度来判断是否显示table，关键致命的还是用v-if（用v-show没问题）
如果使用了v-if那么这两次接口就致命了， 因为请求的是同一个路由， 当pagesize变化去请求接口，如果接口返回的够快，那么页面就会进行刷新， 这是table和分页组件就会因为v-if结束生命周期， 从而不能引发后面的pagechang了，（因为同是异步，不会等你接口回来再进行页面更新的）,组件销毁了后面正确的入参接口无法被触发
解决方案： 页面使用v-show替换v-if， 判断条件由判断数组长度改变为判断total的值是否大于0， 二次接口优化可以使用节流阀，一般为了防止用户重复点击， 都会使用loading 可以将loading作为节流阀
