这是我参与8月更文挑战的第2天，活动详情查看：8月更文挑战

背景

近期的业务实现中，有个很常见的需求，用户输入自动搜索。这个之前也做过，不过做的比较简单，最多就是在发送请求时加防抖处理。但是这次比较特殊的点是我们的搜索功能是个全局的综合搜索，服务端需要同时查8个表，以及调用其他服务才能完成一次搜索，所以对于搜索频次的控制要求非常高。（主要是担心实时调用接口，会给服务端压力过大）

具体实现中遇到的问题的解决办法

自动搜索需要做防抖

在触发自动搜索时，做防抖。这里需要注意防抖控制设置的时间。太短的话，如果接口太慢，还是会对服务器产生一定压力。但是太长的话，就会很影响用户使用体验。因为用户输入到展示搜索结果的时间是：设置的延时+接口请求时间。

按enter键，或者其他容易频繁触发请求的操作，都需要做防抖

如果有按enter键触发搜索的需求，则也需要对请求做防抖处理。

自动搜索和按enter键同时存在时，会触发两次请求

如果自动搜索和按enter键同时存在，需要注意，这种场景下，如果用户按下enter，就会触发两个请求。这种情况下，其实最好的解决方案是，再按下enter的请求发出后，就不要发出后面自动搜索。目前我还没有做取消上一请求的处理，所以还是将两个动作触发的请求都保留。不过这样子，用户是无感知的，因为请求的结果是一样的。但是发两个相同的请求，还是不好的。后续还是需要再优化。（比如记录当前正在搜索的关键字，如果关键字没有变化，就不要发起新请求）

两次连续请求，要处理第一个请求比第二个请求晚回，覆盖最后请求结果的情况

也正是由于我现在没有做上个请求没有回来时，如果发新请求就取消上一次请求的处理，就导致我需要处理：第一次请求比第二次请求晚回来的问题。我们现在处理这个问题的方式是在拦截器里面对接口发出时，记录这个接口的记录唯一标识，然后再在数据返回时，再判断这个请求是不是最新的。如果不是最新的，就舍弃。

总结

做自动搜索时，前端首先要做好请求防抖，另外就是要做好多请求pending时，取消上一请求。