Angular中何时扩展抽象类？继承后为何仍需提供该类？

先看你给出的代码示例：

@Component({
  selector: 'my-component',
  template: `<ng-content></ng-content>`,
  providers: [
    { provide: AbstractClass, useExisting: forwardRef(() => TargetComponent) }
  ]
})
export class TargetComponent extends AbstractClass implements OnInit {

}

一、什么时候该扩展并提供抽象类？ #

• 实现依赖注入的多态性：如果有多个组件/服务遵循同一套行为规范（抽象类定义的规则），但各自实现细节不同，用抽象类作为DI令牌，依赖方只需依赖抽象接口，后续替换实现时不用修改依赖代码。比如定义PaymentService抽象类，子类AlipayService、WechatPayService各自实现支付逻辑，其他组件只注入PaymentService即可，切换支付方式仅需调整DI配置。
• 封装通用逻辑：抽象类可以封装多个子类共享的基础逻辑，子类只需实现差异化部分，同时通过DI提供抽象类令牌，让其他组件能以统一方式注入使用这些子类实例。比如多个表单组件都需要处理通用的表单验证逻辑，抽象类封装后，子类继承并实现自定义渲染逻辑，再注册DI令牌供外部调用。
• 扩展Angular框架能力：Angular的很多扩展点基于抽象类实现，比如自定义表单控件要继承ControlValueAccessor、路由守卫要继承CanActivate，此时必须继承抽象类实现对应方法，同时通过DI注册抽象类令牌，让Angular能识别并调用你的自定义实现。

二、同时继承+提供抽象类的作用 #

这段代码里TargetComponent既继承抽象类又配置providers，核心作用有三点：

1. 让组件实例能以抽象类身份被注入：继承只是让TargetComponent具备抽象类的行为，但Angular的DI系统不会自动关联两者。只有通过providers配置，其他依赖AbstractClass的地方，才能获取到当前TargetComponent的实例。
2. 支持组件自身依赖抽象类：如果TargetComponent的构造函数需要注入AbstractClass，这个配置会让它注入自己的实例，适合递归组件、自我管理状态的组件这类场景。
3. 满足框架识别要求：部分Angular扩展场景中，比如自定义指令要被框架识别为某抽象类型的实现，不仅需要继承抽象类，还要注册DI令牌，框架才能正确触发对应的钩子或抽象类定义的方法。

三、为啥继承了还要配providers？ #

本质是TypeScript类型关系和Angular DI系统的边界问题：

• TypeScript的继承是类型层面的约束，仅保证TargetComponent符合AbstractClass的类型规范，但Angular DI是令牌-实例的映射系统，它不会自动将子类实例关联到父类（抽象类）令牌上，必须手动配置映射关系。
• 假设有另一个AnotherComponent也继承了AbstractClass，如果不配置providers，DI系统无法判断请求AbstractClass时该返回哪个实例。显式配置才能明确：在当前TargetComponent的上下文范围内，AbstractClass对应的就是它自己的实例。
• 组件的providers是局部作用域的，这样可以在当前组件及其子组件范围内，覆盖全局的AbstractClass注入实例，实现局部的多态替换，灵活性更高。

内容的提问来源于stack exchange，提问作者Alan-A