何时应使用exhaustMap而非switchMap？

核心差异快速回顾 #

• switchMap：源Observable发新值时，立刻取消当前未完成的内部Observable（比如pending的API请求），转而订阅新的。适合必须响应最新操作的场景。
• exhaustMap：源Observable发新值时，如果当前有内部Observable在运行，直接忽略这个新值，等当前操作完成后，才会处理后续的新值。

exhaustMap的典型适用场景 #

1. 防止重复触发无意义的相同操作 #

比如表单提交按钮，用户手抖快速点好几次，switchMap会取消前一次请求重新发，但如果两次请求参数完全一致（比如提交同一表单），重复请求既浪费资源，还可能导致后端重复处理（比如重复生成订单）。用exhaustMap就能确保同一操作在完成前不会被重复触发：

submitButtonClick$
  .pipe(
    exhaustMap(() => submitFormApi(formData))
  )
  .subscribe(res => {
    // 处理提交结果
  });

这种场景下，多次点击只会触发一次API请求，直到请求结束后，再次点击才会生效。

2. 处理不允许重复/并发的操作 #

像支付请求、创建资源的POST接口（后端没做幂等处理）这类操作，绝对不能重复执行。exhaustMap可以避免用户误操作导致的重复请求，防止出现重复扣款、重复创建数据的问题。

3. 资源密集型操作的并发控制 #

如果内部Observable是大文件上传、复杂计算这类消耗大量资源的操作，并发执行会拖垮系统性能。exhaustMap能保证同一时间只有一个这类任务在跑，避免资源过载。

4. "最新操作"无价值的场景 #

比如用户点了"刷新数据"按钮，但前一次刷新请求还在加载中，此时新的刷新请求不会拿到更新的数据，反而会增加服务器压力。用exhaustMap忽略重复的刷新请求，等前一次加载完成后再处理后续点击，既省带宽，也避免前端重复处理相同响应。

总结：怎么选？ #

• 用switchMap：需要始终响应最新操作时，比如搜索框输入，每输入一个字符都要发最新的搜索请求，旧请求可以直接取消。
• 用exhaustMap：需要避免重复/并发执行同一类操作时，确保前一次操作完成后才允许下一次，比如表单提交、支付、资源密集型任务。

内容的提问来源于stack exchange，提问作者Heribert Greinix