关于实时检索结果错误的调查

发表于 更新于 本文字数： 712 阅读时长 ≈ 1 分钟
本文介绍关于实时检索结果错误的调查，包括使用场景、实现细节等，以提高关于实时检索结果错误的调查的效率。

问题

用一个例子来描述吧，当用户输入关键词A，触发了检索，一秒钟后，用户输入了关键词 B，触发了检索，这时A检索结果回来了，呈现出来了列表展示，用户诧异，为何输入的B，返回了A结果，再过一会儿B结果回来。用户在可视化的情况下，看到了错误的结果，紧接着看到了正确的结果。

问题思考

接口慢是个问题，但是除了接口慢，也可以看到整个的实时检索存在设计缺陷。

  1. 当触发了第二次请求时，第一次请求如果还在请求中应该中断，这样对于开销来说小一些
  2. 用户之所以会误认为A结果集是用户输入B的结果，还有一个问题是，是否当执行B检索时，就不应该呈现结果集，通过loading等形式呈现给用户还正在检索

百度的实时检索

百度比如输入关键词时，推荐列表并没有loading动画，我想根本原因是因为足够的快，所以不需要有loading

请求取消对后端的影响

如上，当我们取消了一个已经发出的请求，但是因为请求本身是个异步的过程，所以后端还是会把这个请求处理流程走完。所以严格来说，我们取消了请求，对于前端的开销有所减小，但是对于后端无任何影响。

解决方案

  1. 执行新的请求时，如果老的请求还在进行，进行取消

    前端的请求类库，我使用的axios,而本身类库提供了cancel的方案，所以在全局拦截器里进行下配置即可。具体代码可参考这里

  2. 执行请求时，增加loading显示，让用户意识到当前的结果集是历史的，最新的正在检索中

写在最后

经过以上的方案处理，总结下。

  1. 不会呈现错误的结果给用户
  2. 支持了取消pending请求，节约了一定的前端性能开销
  3. 除了上述的两点，也可以对于检索增加防抖处理，比如延迟1秒执行检索，确保高频输入不触发额外的检索。

参考文档