RxJS中正确的错误处理方式是什么？各处理方法适用场景有哪些？

三类错误处理的核心区别 #

1. subscribe 的 error 回调 #

• 定位：整个Observable链路的最终错误兜底，是上游所有操作符均未处理错误时的最后接收入口
• 特点：一旦触发，代表当前Observable已经终止，不会再发射后续值
• 适用场景：不需要恢复链路运行，仅需要做最终错误提示、全局日志上报等兜底逻辑
• 代码示例：

source$.subscribe({
  next: val => console.log('收到数据', val),
  error: err => alert('操作失败：' + err.message)
})

2. tap({ error: err => {} }) 的 error 参数 #

• 定位：错误的旁路监听工具，不介入错误处理流程，仅在错误发生时触发额外副作用逻辑，完全不会改变错误的传播路径
• 特点：回调执行完成后，错误会继续向下游传递，不会被吞掉
• 适用场景：统一的错误埋点、全局日志上报等不需要修改数据流的场景
• 代码示例：

source$.pipe(
  tap({ error: err => reportBuriedPoint('interface_error', err) })
).subscribe(...)

3. catchError 操作符 #

• 定位：唯一支持错误拦截与链路恢复的处理工具，可以拦截上游抛出的错误，选择吞掉错误并返回备用Observable让链路继续运行，也可以抛出新错误向下传递
• 特点：只要在catchError中返回了合法的Observable，下游会正常接收该Observable的发射值，整个链路不会中断
• 适用场景：错误降级（比如请求失败返回默认空数组）、错误重试、业务层自定义错误转换
• 代码示例：

source$.pipe(
  catchError(err => {
    console.error('请求失败，返回默认值', err)
    return of([]) // 返回备用流
  })
).subscribe(res => console.log('始终能拿到返回值', res))

常见问题解答 #

不同错误处理方案的选择逻辑是什么？ #

• 仅需要监听错误做旁路操作（埋点、日志上报），不修改错误流转路径：选择tap的error参数
• 需要拦截错误做降级、重试处理，避免链路终止：选择catchError操作符
• 上游操作符均未处理错误，需要做最终兜底逻辑：选择subscribe的error回调

如果使用了tap的error参数是否还需要搭配catchError？ #

根据业务需求判断：tap的error仅做监听，不会吞掉错误，如果不需要错误恢复，仅需要做上报，后续可以直接走subscribe的error兜底；如果需要避免链路终止、做错误降级，就必须搭配catchError，否则错误还是会传递到subscribe的error导致链路终止。

如果已经使用catchError是否还需要配置subscribe的error参数？ #

如果catchError已经完全处理了所有错误，没有向外抛出新错误，那么subscribe的error永远不会触发，可以不用配置；如果catchError内部可能抛出新错误，或者需要做全局兜底保险，建议还是加上subscribe的error回调，避免漏处理的错误抛出到全局引发控制台报错。

最佳实践规范 #

• 通用错误上报、埋点逻辑优先放在tap的error回调中，复用性更高
• 业务相关的错误降级、重试逻辑放在catchError中，就近处理对应Observable的错误
• 尽量给所有subscribe都加上error回调兜底，避免未处理的错误抛出到全局
• 不要在tap的error中做任何修改数据流的操作，tap仅负责处理副作用逻辑

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