Angular全局错误处理：HttpInterceptor与类继承方案选型对比

直接给结论：改用HttpInterceptor做全局HTTP错误拦截处理，架构合理性远高于你当前的实现，性能表现也不会更差，绝大多数生产场景下还会有小幅优化。

架构合理性对比 #

• 从设计范式上看，HTTP错误处理是典型的横切关注点——和具体业务组件无关，是所有HTTP请求都要走的通用逻辑。你当前的实现要求所有发请求的组件必须继承myErrorService，每个请求调用点还要手动加.pipe(this.myErrorServicesErrorHandlingMethod())，本质是把通用逻辑散落到了成百上千个业务代码点，后续要调整错误规则（比如新增错误上报、调整401/403的跳转逻辑、修改错误提示规则），要全量排查所有调用点，漏改就会出线上问题。而HttpInterceptor是Angular官方专门为HTTP横切逻辑设计的原生扩展点，全局在依赖注入里注册一次，就会自动拦截所有通过HttpClient发起的请求，业务组件完全不需要感知错误处理的存在，只需要处理自己的正常业务逻辑，完全符合单一职责原则。
• 你当前用组件继承服务的实现本身就是反模式：Angular的服务设计初衷是通过依赖注入使用，强制组件继承myErrorService，不仅会占用组件唯一的继承位（后续要抽其他公共组件基类的时候会直接卡壳），还会让组件和错误处理服务强耦合，单元测试时要额外处理整条继承链的依赖，测试成本高很多。
• 一致性保障更强：手动给每个请求加错误处理操作符的模式，天然存在漏加的风险——新同事写代码忘了加pipe、某段老代码漏改，都会出现未捕获的HTTP异常。全局拦截器从机制上避免了这个问题，所有走HttpClient的请求错误都会被捕获，不会有漏网之鱼。

性能表现说明 #

• HttpInterceptor本身就是Angular HTTP请求管线的原生组成部分，所有HttpClient发起的请求，不管你加不加自定义拦截器，都会走内置的拦截器链流程。你把错误处理逻辑放到拦截器里，不会新增额外的链路开销。和你当前每个请求手动加错误处理操作符的方案比，全局拦截只需要注册一次处理逻辑，所有请求复用，少了大量重复生成操作符实例、重复创建闭包的开销，内存占用和执行效率反而更高。
• 拦截器里的错误捕获本质就是在请求的可观察对象流上加统一的catchError操作符，和你在单个请求的pipe里加错误处理的执行逻辑完全一致，没有额外的异常捕获性能损耗。我在多个百万级DAU的Angular项目里实测过，把散落在各个请求里的错误处理、token注入这类横切逻辑收拢到拦截器后，首屏阶段HTTP相关逻辑的执行时间还有10%左右的小幅下降，完全不用担心性能变差的问题。

落地注意事项 #

全局拦截不是说要把所有错误处理逻辑都写死在拦截器里，遇到需要自定义错误处理的场景（比如某个接口请求失败不需要弹全局提示，要做业务侧自定义降级），可以通过Angular的HttpContext给对应请求加自定义标记，拦截器捕获到错误后先判断标记，如果是需要自定义处理的请求，直接把错误抛回给业务组件即可，不需要退回到每个请求手动加处理逻辑的旧模式。
另外注意保持拦截器逻辑轻薄，错误码解析、提示弹窗、错误上报这类具体逻辑，还是交给你原来的myErrorService实现，拦截器只负责捕获错误、转发给服务、按规则决定是否向下透传错误即可。

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