共计 1399 个字符，预计需要花费 4 分钟才能阅读完成。
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 页面：