前端如何防止多次接口请求

结论

1. 如果你是为了解决在极短的时间内多个筛选条件同时变化导致的一次操作发送了多个一样的接口
2. 那么你可以给你的请求方法加一个100ms的防抖去解决多次请求发送的问题
3. 不要问为什么结论写在前面，因为我知道你没时间看

为什么会有多次请求

1. 当你的数据获取需要筛选时，比如表格数据类的获取，为了方便用户，就会支持多个条件的筛选。比如常见的有时间筛选、类别筛选和其他一些业务相关的筛选，经常筛选条件会有3~5个。
2. 正常情况下我们需要收集这些筛选条件，当其中任意一个条件变化，调接口获取数据局部刷新表格。
3. 但复杂情况可能没有我们想象的这么简单，有多重情况会出现用户一次操作其中一个筛选条件发现变化，另一个筛选条件也发生了变化，这就会发送2次请求。或者有些筛选条件依赖本地存储或者依赖后端返回，导致筛选条件多次变化。
4. 如果只是监听数据变化马上就发送请求接口返回数据，在复杂的场景下经常会出现发送多个请求的情况，我们想要的是一个操作只发送一次请求，这显然不太合理。

怎么解决

1. 个人之前遇到这种问题都是十分头疼的，一般都要调试很久才能找到一个合适的方法保证一次操作只能发送一次请求。
2. 有一天我在做表格搜索的时候，为了方便用户在搜索时输入的过程中就去获取表格数据，但是为了避免短时间内发送大量的接口。我给搜索加了500ms的防抖去防止用户正在输入时也发送请求。
3. 突然我悟了，既然我可以通过给输入框加防抖解决短时发大量请求的问题。上述复杂情况，一次操作导致多个筛选条件导致发送了多个请求接口的问题的也可以通过加防抖的方式去解决。因为他们都有一个共同的特点，极短的时间内数据变化不需要也不应该马上去向后台获取数据。而是应该等数据稳定后再去发送请求
4. 所以我同样监听这多个筛选条件，有变化我就会执行获取数据的方法，但是我给这个方法加了一个100ms的防抖，解决了多次请求发送的问题。

存在问题

1. 此种方式比较取巧，延迟ms数可以自行调整，理论上应该50ms也能解决大多数多次请求发送的问题。
2. 复杂问题可以通过这种方式巧妙回避，但是还是建议审查自己的代码查看如何避免多个参数同时变化。