RXJS错误处理差异解析：为何两种写法行为不同？

问题 #

当fetchData()抛出错误时，以下第一个Observable流不会终止，会持续运行：

timer(0, 5000)
  .pipe(
    switchMap(() =>
      fetchData().pipe(
        catchError((err: any) => {
          // 不通过抛出错误终止Observable，而是返回空数组
          return of([]);
        })
      )
    ),
    finalize(() => console.log('finish!'))
  );

我原本认为第二个流会有相同的错误处理效果，但实际并非如此：

timer(0, 5000)
  .pipe(
    switchMap(() => fetchData()),
    catchError((err: any) => {
      // 不通过抛出错误终止Observable，而是返回空数组
      return of([]);
    }),
    finalize(() => console.log('finish!'))
  );

两者的区别在于：第一个示例中catchError直接在fetchData的pipe内，第二个示例中catchError位于switchMap之后。请问为何这两种写法的错误处理行为会存在差异？

回答 #

核心差异在于**catchError的作用范围不同**，这直接决定了错误是否会传播到上游的timer流：

• 第一种写法：catchError在fetchData的pipe内
  fetchData抛出错误后，自身pipe里的catchError会立即捕获错误，返回of([])作为替代值。这个错误完全被局限在switchMap内部的子流中，不会向上传播到外层的timer流。因此timer流不受影响，依然会每隔5秒正常触发新的fetchData请求，整个主流不会终止。

• 第二种写法：catchError在switchMap之后
  当fetchData抛出错误时，错误会从子流传播到switchMap，再继续向上传到外层的catchError。RxJS的规则是：一旦Observable流抛出错误，整个流就会立即终止，catchError只是在流终止前提供一个替代的收尾值（这里是of([])）。当错误被外层catchError处理后，整个主流（包括上游的timer）已经终止，自然不会再继续触发后续的请求。

简单总结：第一种是在子流内部消化错误，不干扰主流程；第二种是错误导致整个主流终止，再用替代值完成收尾。

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