当Observable请求耗时超5秒时switchMap订阅失效，如何解决轮询问题？

你的问题核心在于switchMap的特性：每当源Observable（这里的timer(1, 5000)）发出新值时，它会立即取消之前仍在运行的内部Observable（gatewayService.get）。如果你的请求耗时超过5秒，下一个timer触发时，未完成的请求就会被强制取消，导致订阅中断、轮询失效。

根据不同的业务需求，这里有几种靠谱的解决方案：

方案1：等待前一个请求完成后再发起下一轮询（保证请求顺序，无并发） #

如果你的业务不需要严格的5秒固定间隔，而是希望「上一次请求完成后，再等5秒发起下一次」，可以用concatMap替代switchMap。concatMap会等待前一个内部Observable完成后，才会订阅下一个，完全避免了请求被取消的问题：

startPolling() { 
  timer(1, 5000).pipe( 
    concatMap(() => this.gatewayService.get(this.id)), // 替换为concatMap
    retry(), 
    share(), 
    takeUntil(this.stopPolling) 
  ).subscribe((gateway) => { 
    this.status = gateway.status; 
    this.stopPollingIfImageDownloaded(); 
  }); 
}

注意：如果请求耗时不稳定，轮询的实际间隔会变成「请求耗时 + 5秒」，比如请求花了6秒，那下一次请求会在6+5=11秒后发起。

方案2：严格固定间隔发起请求（允许并发） #

如果必须保证每5秒发起一次请求，哪怕前一个请求还在运行，可以用mergeMap。不过这种情况要注意服务器压力，避免短时间内堆积太多请求：

startPolling() { 
  timer(1, 5000).pipe( 
    mergeMap(() => this.gatewayService.get(this.id)), // 替换为mergeMap
    retry(), 
    share(), 
    takeUntil(this.stopPolling) 
  ).subscribe((gateway) => { 
    this.status = gateway.status; 
    this.stopPollingIfImageDownloaded(); 
  }); 
}

提示：如果想限制并发数（比如最多同时运行2个请求），可以用mergeMap(() => ..., 2)。

方案3：忽略新的轮询触发，直到当前请求完成（避免并发，跳过重叠请求） #

如果你的需求是：当请求还在处理时，跳过下一次的轮询触发，直到当前请求完成后，再继续按5秒间隔发起。这种场景适合用exhaustMap，它会忽略源Observable的新值，直到当前内部Observable完成：

startPolling() { 
  timer(1, 5000).pipe( 
    exhaustMap(() => this.gatewayService.get(this.id)), // 替换为exhaustMap
    retry(), 
    share(), 
    takeUntil(this.stopPolling) 
  ).subscribe((gateway) => { 
    this.status = gateway.status; 
    this.stopPollingIfImageDownloaded(); 
  }); 
}

举个例子：如果第一个请求花了7秒，那么第5秒时的timer触发会被忽略，等第7秒请求完成后，下一次请求会在第7+5=12秒发起。

方案4：固定间隔+请求完成后更新（精准链式轮询） #

如果想要严格的5秒间隔（从请求完成后开始计算），同时只在请求完成后更新状态，可以用expand操作符实现链式轮询——每次请求完成后，等待5秒再发起下一次：

startPolling() { 
  this.gatewayService.get(this.id).pipe(
    expand(() => timer(5000).pipe(
      switchMap(() => this.gatewayService.get(this.id))
    )),
    retry(),
    takeUntil(this.stopPolling)
  ).subscribe((gateway) => {
    this.status = gateway.status;
    this.stopPollingIfImageDownloaded();
  });
}

这种方式的优势是：完全不会出现请求被取消的情况，同时保证了状态更新的顺序性，轮询间隔始终是上一次请求完成后的5秒。

总结选择建议： #

• 优先考虑方案1（concatMap）或方案4（expand）：这两种方式最符合常规轮询的需求，避免请求被取消，同时保证状态更新的可靠性。
• 如果必须严格固定间隔发起请求，再考虑方案2（mergeMap），但要注意并发压力。
• 如果不希望同时运行多个请求，且可以跳过重叠的轮询触发，选方案3（exhaustMap）。

内容的提问来源于stack exchange，提问作者Amar T