Angular拦截器中JWT令牌刷新的RxJs纯响应式实现问询

我正在开发以REST API为后端的Angular SPA应用，采用HttpOnly Cookie存储JWT令牌，通过拦截器处理令牌过期后的刷新流程。目前的实现过度依赖顺序编码，而非完全基于Observable实现。以下是我编写的handle401Error函数代码：

private handle401Error(request: HttpRequest<any>, next: HttpHandler):Observable<HttpEvent<any>> | Observable<never> {

if(!this.isRefreshing$.value) {
  this.isRefreshing$.next(true);

  return this.authenticationService.isUserLoggedIn$.pipe(
    takeUntil(this.isRefreshing$.pipe(filter(isRefreshing => !isRefreshing))),
    switchMap(isLoggedIn => {
      if(isLoggedIn){
        return this.authenticationService.refreshToken().pipe(
          switchMap(() => {
              this.isRefreshing$.next(false);

              return next.handle(request);
          }),              
          catchError((error) => {
              if (error.status == '403' || error.status == '400') {
                this.store.dispatch(LoginActions.falseLogout());
              }

              this.isRefreshing$.next(false);
              return throwError(() => error);
          })
        )
      } else {
        return NEVER;
      }
      })
  )
}

return this.isRefreshing$.pipe(
  withLatestFrom(this.authenticationService.isUserLoggedIn$),
  skipWhile(([isRefreshing,isLoggedIn]) => isRefreshing),
  take(1),
  switchMap(([isRefreshing,isLoggedIn]) => {
    if(isLoggedIn) {
      return next.handle(request)
    } else {
      return NEVER;
    }
  })
)}

该函数第一部分创建刷新周期，尝试刷新令牌成功后重发请求；第二部分在令牌刷新期间将后续请求排队。当前代码可正常运行，但我希望采用纯RxJs方式实现，移除函数开头的if判断，请问该方案是否可行？现有实现是否已是较好的解决方案？

解答 #

纯RxJS改造方案完全可行 #

完全用纯RxJS移除开头的if判断是可行的，而且这种实现更贴合RxJS的响应式编程理念，避免了直接访问Observable的value属性（这属于命令式操作，容易破坏响应式流的状态一致性）。

改造后的纯RxJS实现示例 #

核心思路是通过isRefreshing$的状态流来分支逻辑，把所有判断都融入Observable管道中：

private handle401Error(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> | Observable<never> {
  return this.isRefreshing$.pipe(
    take(1),
    switchMap(isRefreshing => {
      // 未在刷新时，触发令牌刷新流程
      if (!isRefreshing) {
        return this.authenticationService.isUserLoggedIn$.pipe(
          take(1),
          switchMap(isLoggedIn => {
            if (!isLoggedIn) return NEVER;
            
            // 标记开始刷新
            this.isRefreshing$.next(true);
            
            return this.authenticationService.refreshToken().pipe(
              switchMap(() => {
                this.isRefreshing$.next(false);
                return next.handle(request);
              }),
              catchError(error => {
                if (error.status === 403 || error.status === 400) {
                  this.store.dispatch(LoginActions.falseLogout());
                }
                this.isRefreshing$.next(false);
                return throwError(() => error);
              })
            );
          })
        );
      } 
      // 正在刷新时，等待刷新完成后重发请求
      else {
        return this.isRefreshing$.pipe(
          withLatestFrom(this.authenticationService.isUserLoggedIn$),
          skipWhile(([refreshing]) => refreshing),
          take(1),
          switchMap(([_, isLoggedIn]) => isLoggedIn ? next.handle(request) : NEVER)
        );
      }
    })
  );
}

现有实现的优缺点分析 #

优点

• 逻辑拆分清晰，分场景处理的模式易于理解
• 功能完整，能正常完成令牌刷新和请求排队的需求

缺点

• 直接访问isRefreshing$.value是命令式操作，违背了RxJS响应式编程的核心思想，极端异步场景下可能出现状态不一致的问题
• 代码混合了命令式和响应式逻辑，不够纯粹，长期维护性略差

总结 #

纯RxJS的改造方案不仅可行，而且更符合响应式编程的最佳实践，能规避命令式操作带来的潜在风险。如果团队追求代码的纯净性和可维护性，建议进行改造；如果现有代码已经稳定运行且团队成员理解成本低，也可以保留，但从长期来看，纯响应式实现的扩展性和健壮性更优。

内容的提问来源于stack exchange，提问作者Endika Campo Acha