Angular 按照开发人员提供的 HTTP Interceptors 的顺序来依次 调用这些拦截器。
例如，考虑这种例子，开发人员希望处理 HTTP 请求的身份验证，并在将它们发送到服务器之前记录它们。要完成这个场景，可以按顺序先提供 AuthInterceptor，然后再提供 LoggingInterceptor. Angular 应用发送出的请求，将从 AuthInterceptor 流向 LoggingInterceptor。相应的，这些请求的响应将反向流动，即从 LoggingInterceptor 返回到 AuthInterceptor.
以下是该过程的图形化表示：
流程中的最后一个拦截器始终是处理与服务器通信的 HttpBackend.
SAP Spartacus 开发中为令牌 HTTP_INTERCEPTORS 提供的绝大多数 Interceptor，都定义在 barrel 文件即 index.ts 内：
这些 Interceptor 彼此之间在业务上并没有依赖关系，所以没有严格的先后顺序定义要求。
大多数 HttpClient 方法返回 HttpResponse<any> 的 observables。 HttpResponse 类本身实际上是一个事件，其类型为 HttpEventType.Response. 但是，单个 HTTP 请求可以生成多个其他类型的事件，包括上传和下载进度事件。 HttpInterceptor.intercept() 和 HttpHandler.handle() 方法返回 HttpEvent<any> 的 observables.
下面是 SAP Spartacus 一个具体的 Interceptor 例子：
许多拦截器只关心传出请求并从 next.handle() 返回事件流而不修改它。 然而，一些拦截器需要检查和修改来自 next.handle() 的响应； 这些操作需要识别到流中的所有这些事件。
上图是 Spartacus Cart Checkout 场景使用 Interceptor 进行错误处理的一个例子。
首先从 rxjs/operators 里导入 Rxjs 执行错误处理的操作符 catchError：
当 HTTP 交互出现错误时，传入 catchError 操作符的箭头函数触发，如果触发时的实例变量 response 的类型为 HttpErrorResponse，那么继续判断当前的路由路径，是否包含了 checkout 片段：
这个判断通过下列函数执行：
/** * Returns true if the parameter semantic route is part of "checkout" * Checkout semantic routes: * checkout * checkoutPaymentType * CheckoutShippingAddress * checkoutDeliveryMode * checkoutPaymentDetails * checkoutReviewOrder * checkoutLogin * @param semanticRoute */ protected isUserInCheckoutRoute(semanticRoute?: string): boolean { return semanticRoute?.toLowerCase().startsWith('checkout') ?? false; }
如果上述函数返回 true，则通过 this.routingService.go, 重定向到 cart 页面：
