嵌套RxJS concatMap转async-await的可行性及优劣对比

Angular开发中经常遇到后续HTTP请求完全依赖前序请求返回结果的串行请求场景，典型流程为：先请求获取formConfig配置，再使用返回的formConfig中的id拉取申请记录，之后依次执行后续依赖接口请求。针对这类场景，常见疑问包括：将嵌套RxJS concatMap的写法改写为async-await形式避免回调地狱，是否具备更高的可读性与可维护性？两种写法各有哪些优缺点？哪种写法更便于实现错误处理？

两种写法的代码示例 #

常规嵌套concatMap写法 #

ngOnInit(){
   this.http.get(`/app-config/${this.appType}`)
   .pipe(
       concatMap(formConfig => {
           this.formConfig = formConfig;
           return this.http.get(`/appl/${this.formConfig.id}`);
       }),
       concatMap(applRec => {
           this.applRec = applRec;
           return this.http.get(`/xxx/${this.applRec.recNo}`)          
       }),
       tap((val) => {this.xxx = val})
       // 可继续追加其他操作符逻辑
   ).subscribe();
}

async-await结合toPromise的改写写法 #

constructor(){
 this.init().then();
}
async init() {
  this.formConfig = await this.http.get(`/app-config/${this.appType}`).toPromise();
  this.applRec = await this.http.get(`/appl/${this.formConfig.id}`).toPromise();
  this.xxx = await this.http.get(`/xxx/${this.applRec.recNo}`).toPromise();
}

两种写法优缺点对比 #

async-await写法 #

优点

• 代码为线性从上到下的执行逻辑，和串行请求的实际执行顺序完全一致，没有RxJS操作符的链式心智负担，对RxJS不熟悉的开发者读代码几乎没有学习成本，简单固定串行场景下可读性更高。
• 变量赋值逻辑平铺，不需要在各个concatMap回调中反复编写赋值逻辑，同等逻辑下代码行数更少。
• 调试成本低，可以直接在每一行await处打断点，逐行查看变量赋值结果，不需要在RxJS各个操作符中来回跳转加断点。

缺点

• 会丢失RxJS原生的流控制能力：如果后续需要加请求重试、超时控制、防抖、手动取消、竞态处理、中间结果转换复用等逻辑，async-await实现起来非常繁琐，远不如RxJS操作符开箱即用。比如要给第一个请求加3秒超时、失败自动重试2次，concatMap写法只要在pipe中追加timeout(3000)、retry(2)两个操作符即可，async-await需要自行封装超时逻辑、手写重试循环。
• 请求取消实现成本高：Angular HttpClient返回的是冷Observable，取消订阅即可自动中断未完成的HTTP请求；但Promise没有原生取消能力，要实现切页取消请求的效果，需要额外引入AbortController做适配。
• 存在API兼容隐患：RxJS 7+版本已经将toPromise()标记为废弃，官方推荐使用firstValueFrom/lastValueFrom做Observable到Promise的转换，旧写法在版本升级时可能出现兼容问题。
• 示例中的写法本身不符合Angular最佳实践：在构造函数中直接调用async初始化函数、且未传入错误回调，既容易出现构造函数执行完成但数据未加载完成的时序问题，也容易遗漏请求异常导致未捕获的Promise报错。

concatMap写法 #

优点

• 完整保留RxJS响应式能力，所有流控制操作符可以直接接入，不管后续需要加超时、重试、取消、错误兜底、结果缓存、竞态处理，都可以通过链式追加操作符实现，扩展性极强。
• 天然支持请求生命周期管理：组件销毁时只要调用订阅对象的unsubscribe()方法，就会自动取消所有未返回的HTTP请求，不会出现组件销毁后请求返回、赋值触发视图更新报错的问题。
• 错误处理颗粒度更灵活：既可以在流的尾部统一加catchError做全链路错误处理，也可以针对某一个concatMap内的单独请求加错误捕获逻辑，不需要额外嵌套代码块。
• 适配复杂异步流程：如果串行流程中某一步需要根据返回结果走分支请求、或者中途需要结合其他响应式数据源（比如路由参数变化、表单值变化触发重新请求），concatMap可以直接和其他Observable组合，不需要重写整个异步逻辑结构。

缺点

• 存在RxJS学习门槛：如果开发者对高阶映射操作符不熟悉，很容易误将concatMap写成switchMap、mergeMap引发逻辑bug（比如switchMap会取消前序未完成请求，串行场景下如果前序请求响应慢会被直接打断）。
• 纯简单串行场景下，链式操作符的写法相比线性的async-await可读性稍差，尤其是每个操作符回调内逻辑复杂、嵌套层级深的时候，容易出现类似回调地狱的观感。

错误处理便利性对比 #

两种写法的错误处理成本要分场景看：

• 如果只是做全链路统一错误捕获，两者成本基本一致：async-await只要在最外层包一层try/catch块就能捕获所有await步骤抛出的错误；concatMap只要在subscribe的error回调、或者pipe尾部加catchError操作符，就能捕获整个流的异常。
• 如果需要做分步骤精细化错误处理，concatMap的灵活性明显更高：async-await如果要单独捕获某一个请求的错误，需要给每一行await单独套一层try/catch，会产生大量嵌套代码；concatMap可以针对单个请求的Observable单独追加catchError，处理完错误后返回默认值或者抛出指定错误即可，不会增加代码嵌套层级。

需要注意的是，两种写法如果不做错误处理，风险是一致的：RxJS流未捕获的错误会终止整个流并抛出异常，async/await未捕获的Promise reject会触发未处理Promise拒绝报错。

选型建议 #

• 如果是3步以内的固定纯串行请求，后续确定没有扩展流控制的需求，团队成员RxJS熟悉度普遍不高，用async-await写法完全可行，可读性更好。
• 如果串行流程后续可能追加超时、重试、取消、分支逻辑、或者需要和其他响应式数据源联动，优先选择concatMap写法，长期可维护性更高。

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