Angular 组件继承深度解析：metadata 如何从基类合并，源码中 ɵɵInheritDefinitionFeature 又做了什么

本文基于 Angular 官方文档仓库中的 组件继承指南 展开，系统讲解 Angular 组件/指令继承的三类规则：装饰器 metadata 的联合继承、依赖注入在父子类间的传递方式、生命周期方法的覆写语义，并结合 inherit_definition_feature.ts 源码与 inherit_definition_feature_spec.ts 测试，剖析运行时如何完成 metadata 合并。读完本文，你能理解“子类拿到祖先 inputs/outputs/host bindings 的并集”这一行为背后的实现机制，并知道哪些继承用法（如指令继承组件）会被框架直接拒绝。

前提：本篇假设你已经了解 Angular 组件基础（可先阅读仓库中 components 章节下的 生命周期、输入输出 等配套文档），本文聚焦“继承”这一专题。

一、组件就是 TypeScript 类：可以继承任意基类

Angular 组件本质上是 TypeScript 类，天然参与标准的 JavaScript 继承语义。一个组件可以继承任何基类——无论基类是否带装饰器。最基础的情形是，基类只是一个普通类，子类继承其字段与方法：

export class ListboxBase {
  value: string;
}

@Component(/* ... */)
export class CustomListbox extends ListboxBase {
  // CustomListbox inherits the `value` property.
}

这类“纯类继承”不涉及 Angular metadata，完全由 JavaScript 原型链完成。真正有意思的是下一节：当基类本身也是组件或指令时，框架还会额外合并两层信息——装饰器上的 metadata（selector、host 绑定、inputs/outputs 声明等）和基类中被装饰的成员（@Input、@Output、@HostListener、@HostBinding 等）。

二、继承组件/指令时：metadata 取“并集”

原文档给出的核心示例展示了父子组件的 metadata 合并规则。基类组件声明了 key 事件宿主绑定和一个必填 input value，子类声明了自己的 selector、template、click 宿主绑定和一个新 input disabled：

@Component({
  selector: 'base-listbox',
  template: ` ... `,
  host: {
    '(keydown)': 'handleKey($event)',
  },
})
export class ListboxBase {
  value = input.required<string>();
  handleKey(event: KeyboardEvent) {
    /* ... */
  }
}

@Component({
  selector: 'custom-listbox',
  template: ` ... `,
  host: {
    '(click)': 'focusActiveOption()',
  },
})
export class CustomListbox extends ListboxBase {
  disabled = input(false);
  focusActiveOption() {
    /* ... */
  }
}

按文档结论，CustomListbox 继承了 ListboxBase 的全部信息（value input 和 keydown 监听），同时用自己的 selector 和 template 覆盖了基类的对应值。最终 CustomListbox 拥有两个 inputs（value 和 disabled）、两个事件监听（keydown 和 click）。

用一句话概括这条规则（原文档原话的翻译）：

子类最终获得的是其所有祖先的 inputs、outputs、host bindings 与其自身声明的“并集”（union）。

需要注意的是，这个并集不是无条件覆盖：同名的 input 以子类自己的声明为准，基类的同名声明（包括其 transform）会被跳过，这一点下文会结合源码 mergeInputsWithTransforms 和测试用例说明。

源码级解析：ɵɵInheritDefinitionFeature 合并的到底有哪些字段

Angular 的 AOT 编译器在为带继承的类生成 ɵcmp/ɵdir 定义时，会注入一个名为 ɵɵInheritDefinitionFeature 的“特性函数”（feature）。在 AOT 侧，view compiler 中可以看到它的注入位置与顺序约束：

// Note: host directives feature needs to be inserted before the
// inheritance feature to ensure the correct execution order.
if (meta.hostDirectives?.length) {
  features.push(
    o
      .importExpr(R3.HostDirectivesFeature)
      .callFn([createHostDirectivesFeatureArg(meta.hostDirectives)]),
  );
}
if (meta.usesInheritance) {
  features.push(o.importExpr(R3.InheritDefinitionFeature));
}
if (meta.lifecycle.usesOnChanges) {
  features.push(o.importExpr(R3.NgOnChangesFeature));
}

JIT（ngc 之外的运行时编译路径）则通过 jit/environment.ts 中 'ɵɵInheritDefinitionFeature': r3.ɵɵInheritDefinitionFeature 的映射提供同一实现。

真正的合并逻辑在 inherit_definition_feature.ts 的 ɵɵInheritDefinitionFeature(definition) 中，其流程可以拆解为五步：

1. 沿原型链向上遍历，只认“自有”定义。 函数先用 getSuperType（Object.getPrototypeOf(type.prototype).constructor）取到父类，然后循环向上。这里有一个刻意的安全设计（源码注释原文：Only accept defs declared on the current type to avoid polluted prototype members）：它用 Object.hasOwn(superType, NG_COMP_DEF) / Object.hasOwn(superType, NG_DIR_DEF) 只读取直接挂在类自身上的 ɵcmp/ɵdir，而不是通过原型链查找。对应测试 “should ignore inherited ɵdir from polluted Object.prototype” 模拟了 Object.prototype 被污染出 ɵdir 的场景，断言子类的 hostAttrs 仍为 null，证明该防护有效。

2. 按规则选取父定义（含一条硬性报错规则）。 如果当前定义是组件，父定义取父类的 ɵcmp 或 ɵdir；如果当前定义是指令而父类是组件，直接抛出运行时错误：

throw new RuntimeError(
  RuntimeErrorCode.INVALID_INHERITANCE,
  `Directives cannot inherit Components. Directive ... is attempting to extend component ...`,
);

对应错误码为 NG0903，验收测试 inherit_definition_feature_spec.ts 第一条用例正是断言该错误：'NG0903: Directives cannot inherit Components. Directive MyDirective is attempting to extend component MyComponent'。这是继承规则中唯一会“直接失败”的组合——组件可以继承指令，指令不能继承组件。

3. 合并 inputs/outputs 与 host bindings、queries、animations。 对每一层祖先定义（源码 L74-L106）：

• inputs：mergeInputsWithTransforms（L135-L151）遍历父类 inputs，仅当子类自己的 inputs 中不存在同名 key 时才从父类拷贝，并同步拷贝 declaredInputs（transform 函数）。也就是说：子类重新声明了同名 input，则父类的 transform 不继承；子类未声明，则父类的 input 及其 alias/transform 一并继承。验收测试 “should not inherit transforms if inputs are re-declared” 与 “should inherit transforms if inputs are aliased” 分别验证了这两个分支：重新声明时 someInput 保持原始值 'newValue'，未重新声明（仅走 alias publicName）时 transform 生效得到 'newValue-transformed'。
• outputs：fillProperties(definition.outputs, superDef.outputs) 做同样的“子优先”合并；测试 “should inherit outputs” 验证了父类 @Output() foo 能在子类模板上以 (foo) 监听并收到 'test'。
• host bindings：inheritHostBindings（L215-L228）不是“替换”而是包装——如果子类已有 hostBindings，则生成一个先执行父级、再执行子级的新函数；否则直接复用父级函数。这就是为什么文档示例中 CustomListbox 同时拥有 keydown（父）和 click（子）两个监听。
• queries：inheritViewQuery / inheritContentQueries（L188-L213）采用同样的“先父后子”包装策略，因此父子两级的 @ViewChild/@ViewChildren 与 @ContentChild/@ContentChildren 都会执行。
• animations：若父级是组件且声明了 animations，则把父级动画数组拼接到子级 data.animation 之后。

4. 合并 hostAttrs / hostVars。 mergeHostAttrsAcrossInheritance（L160-L174）从继承链最顶端向叶子方向累加：每一级的 hostVars 变成“祖先 hostVars 之和 + 本级 hostVars”，hostAttrs 用 mergeHostAttrs 逐层合并。多子类场景下这一累加结果被 “multiple children” 测试 精确断言：BaseDirective.hostVars = 2、SuperDirective.hostVars = 4、Sub1Directive/Sub2Directive 均为 6。

5. 执行祖先 features，且防止“多重包装”。 遍历父级 features 列表时，带 ngInherit 标记的特性（如 NgOnChangesFeature）会在子类定义上重新执行，这正是 ngOnChanges 能够“继承”的机制——验收测试专门覆盖了 super 是指令、是普通类、甚至未加装饰的中间基类（基类继承自带装饰的祖先）等六种组合（见 ngOnChanges 测试组）。同时，一旦在祖先 features 中发现 ɵɵInheritDefinitionFeature 本身，shouldInheritFields 被置为 false：因为该祖先定义已经包含了它自己的全部祖先信息，字段合并可以短路，只需继续向上收集可能存在的其它 features。这个设计解决了源码注释里提到的“多重子类导致父级 hostBindings 被重复包装”问题——multiple children 测试 中 Sub1/Sub2 共享祖先 Super/Base，日志严格断言每条祖先逻辑各执行一次（Base.backgroundColor、Super.color、Sub1.height 各出现一次），不会因原型链被两条路径遍历而双重执行。

三、依赖注入的继承：inject() 与构造函数参数两种姿势

原文档对 DI 在继承中的行为给出了两种截然不同的处理方式，这是继承组件库时最容易踩坑的地方。

姿势一：基类用 inject() 作属性初始化器。 此时子类自动继承该属性，无需任何 super 转发：

@Component(/* ... */)
export class ListboxBase {
  protected element = inject(ElementRef);
}

@Component(/* ... */)
export class CustomListbox extends ListboxBase {
  // `element` is inherited from `ListboxBase`.
}

原因在于 inject() 在属性初始化阶段执行，依赖当前类的实例化注入器（static injector）自动解析，父类构造函数被隐式调用时属性初始化器随之运行，子类无需知晓注入了什么。

姿势二：基类用构造函数参数注入。 此时子类必须显式把依赖传给 super，否则 TypeScript/JavaScript 层面父类构造函数收不到依赖：

@Component(/* ... */)
export class ListboxBase {
  constructor(private element: ElementRef) {}
}

@Component(/* ... */)
export class CustomListbox extends ListboxBase {
  constructor(element: ElementRef) {
    super(element);
  }
}

实践含义很直接：写“可继承的组件基类”时优先使用 inject() 字段初始化风格，可以避免每个子类都被迫重写一遍构造函数与依赖透传。

四、生命周期方法的继承与覆写

生命周期钩子（ngOnInit、ngDoCheck、ngOnDestroy 等）不走 metadata 合并，走的是标准 JavaScript 方法覆写：子类定义同名方法即覆盖基类实现，想保留基类逻辑必须显式 super 调用。原文档示例：

@Component(/* ... */)
export class ListboxBase {
  protected isInitialized = false;
  ngOnInit() {
    this.isInitialized = true;
  }
}

@Component(/* ... */)
export class CustomListbox extends ListboxBase {
  override ngOnInit() {
    super.ngOnInit();
    /* ... */
  }
}

两点补充证据值得注意：

1. 钩子的执行顺序由验收测试钉死。 lifecycle hooks 测试组 对 ngOnInit/ngDoCheck/ngAfterContentInit/ngAfterContentChecked/ngAfterViewInit/ngAfterViewChecked/ngOnDestroy 逐一验证：未覆写的钩子执行基类版本，覆写时子类版本替换基类版本。例如 ngOnInit 用例中，子类覆写 ngOnInit 后日志为 ['sub init', 'super do check', 'super after content init', ...]——super init 被完全替换为 sub init，而其余未覆写钩子照常走基类实现。
2. ngOnChanges 是“特例中的特例”。 它不依赖模板 input 声明本身，而是由编译器注入 NgOnChangesFeature 实现；该特性带 ngInherit 标记，会在子类定义上重放，因此即使中间基类没有加任何 Angular 装饰器，只要链上某处定义了 ngOnChanges，子类也会执行它。测试 “should be inherited from undecorated super class which inherits from decorated one” 专门覆盖了 abstract class UndecoratedBase extends Base（无装饰）这种链路，断言 changes 恰好自增 1 次（不重复执行）。

五、继承规则的边界与验证入口

汇总原文档与源码共同确认的规则边界：

场景	行为	依据
组件继承普通类	正常，仅 JS 继承	inheritance.md
组件继承组件/指令	metadata 并集继承，selector/template 等子类自有配置生效	inheritance.md、mergeInputsWithTransforms
指令继承指令	正常	验收测试多组用例
指令继承组件	抛错 NG0903（INVALID_INHERITANCE）	inherit_definition_feature.ts L62-L70、测试 L36-L69
基类 inject() 字段	自动继承，无需 super	inheritance.md
基类构造函数参数注入	子类必须 super(dep) 转发	inheritance.md
覆写生命周期钩子	子类版本完全替换基类版本，需 super.ngOnInit() 才能保留基类逻辑	inheritance.md、lifecycle hooks 测试组

若你希望自行验证本文结论，可以直接阅读 packages/core/test/acceptance/inherit_definition_feature_spec.ts——它覆盖了错误抛出、多子类不重复执行、inputs/outputs 继承与 alias/transform 语义、六种 ngOnChanges 继承链、以及七个生命周期钩子的覆写行为，是“组件继承”这一主题在本仓库中最完整的行为契约。

六、实践建议

• 设计可复用的组件/指令基类时，依赖一律用 inject() 字段初始化，降低子类的构造函数负担。
• 覆写生命周期钩子时习惯性先写 super.xxx() 再写子类逻辑，避免静默丢失基类初始化。
• 组件库中常见“一个抽象基类 + 多个具体子类”的结构（如文档示例的 ListboxBase/CustomListbox），从源码看框架已用 shouldInheritFields 短路机制保证共享祖先的 hostBindings 不会被多重包装，多子类结构可以放心使用。
• 永远不要让 @Directive 去 extends 一个 @Component，该组合在运行时会直接以 NG0903 失败。