Angular按照开发者提供的HTTPInterceptor的顺序依次调用这些拦截器。例如，考虑开发人员想要处理HTTP请求的身份验证并在将它们发送到服务器之前记录它们的情况。要完成此场景，可以按顺序提供AuthInterceptor，然后是LoggingInterceptor。来自Angular应用程序的请求将从AuthInterceptor流向LoggingInterceptor。相应地，对这些请求的响应将反向流动，从LoggingInterceptor返回到AuthInterceptor。以下是流程的图形表示：流程中的最后一个拦截器始终是处理与服务器通信的HttpBackend。HTTP_INTERCEPTORS这个品牌提供的Interceptor大部分都定义在桶文件中，即index.ts：这些Interceptor之间没有业务依赖，所以没有严格的顺序定义要求。大多数HttpClient方法返回HttpResponse的可观察值。HttpResponse类本身实际上是一个HttpEventType.Response类型的事件。但是，单个HTTP请求可以生成多种其他类型的事件，包括上传和下载进度事件。HttpInterceptor.intercept()和HttpHandler.handle()方法返回HttpEvent的可观察对象。这是SAPSpartacus的具体拦截器示例：许多拦截器只关心传出请求并从next.handle()返回事件流而不修改它。但是，一些拦截器需要检查和修改来自next.handle()的响应；这些操作需要识别流中的所有此类事件。上图是使用Interceptor进行错误处理的SpartacusCartCheckout场景示例。首先，从rxjs/operators导入Rxjs错误处理运算符catchError：当HTTP交互发生错误时，触发传递给catchError运算符的箭头函数。如果触发时实例变量response的类型是HttpErrorResponse，则继续判断当前Routing路径，是否包含checkout段：这个判断由下面的函数执行：/***如果参数语义route是part则返回true“checkout”*Checkout语义路由：*checkout*checkoutPaymentType*CheckoutShippingAddress*checkoutDeliveryMode*checkoutPaymentDetails*checkoutReviewOrder*checkoutLogin*@paramsemanticRoute*/protectedisUserInCheckoutRoute(semanticRoute?:string):boolean{returnsemanticRoute?.toLowerCase().startsWith('查看'）？？错误的;}如果上面的函数返回true，传递this.routingService。去，重定向到购物车页面：
