Angular基类使用BehaviorSubject<this>时传子类构造函数类型报错

该编译错误和Angular模板编译器无直接关联，是TypeScript泛型变异性校验规则与RxJS类型定义共同作用的结果：

• 类中声明的多态this类型，在子类继承时会被自动替换为子类自身的实例类型。当将子类构造函数传入声明为接收基类构造函数的参数时，TypeScript会校验两个类的实例结构是否完全兼容。
• 泛型类型的兼容性由类型参数的变异性决定：
  • 类型参数仅出现在输出位置时（如Promise<T>的T仅作为回调返回值、无成员的自定义泛型SomeGeneric<T>未实际使用T），泛型为协变：子类型的泛型实例可直接赋值给父类型的泛型实例，因此Promise<ExtClass>与Promise<BaseClass>兼容，不会触发错误。
  • 类型参数同时出现在输入（方法参数）和输出（方法返回值）位置时，在strictFunctionTypes开启（strict模式默认开启）的场景下，泛型为不变：仅当类型参数完全一致时，两个泛型实例才互相兼容。BehaviorSubject<T>属于这类不变泛型：它既包含next(value: T)这类接收T的输入成员，也包含getValue(): T这类返回T的输出成员，因此BehaviorSubject<ExtClass | null>与BehaviorSubject<BaseClass | null>互不兼容，最终抛出类型不匹配错误。
• 纯TypeScript环境与Angular环境表现不一致的核心原因是依赖版本绑定差异：Angular对TypeScript、RxJS的版本有严格的兼容范围限制，纯TS环境的TypeScript或RxJS版本可能刚好未触发该严格校验，因此编译通过。

按类型安全度从高到低排序：

1. 使用显式泛型参数替代多态this
   这是最推荐的方案，既保留完整的类型推导能力，又完全符合类型校验规则：

   class SomeGeneric<T> {}
   
   // 基类增加泛型参数，约束为基类自身的子类型
   class BaseClass<T extends BaseClass = BaseClass> {
     public thisSubject$: BehaviorSubject<T | null> | undefined;
     public thisPromise: Promise<T> | undefined;
     public thisSome = new SomeGeneric<T>();
   }
   
   // 子类继承时传入自身类型作为泛型参数
   class ExtClass extends BaseClass<ExtClass> {
     public anotherField: number = 0;
   }
   
   function takesCtor(ctor: typeof BaseClass) {
     console.log(ctor);
   }
   
   takesCtor(ExtClass); // 正常编译
   

2. 局部类型断言绕过校验
   如果不想调整类的结构，可在传参位置做显式类型断言，仅跳过这一处的兼容性检查：

   takesCtor(ExtClass as typeof BaseClass);
   

   注意该方案会丢失这部分的类型安全保障，仅适合临时修复场景。
3. 显式指定字段为基类类型
   如果不需要子类的多态this推导，可直接将BehaviorSubject的泛型参数声明为基类类型，放弃多态特性：

   class BaseClass {
     public thisSubject$: BehaviorSubject<BaseClass | null> | undefined;
     // 其余字段不变
   }
   

4. 关闭严格函数类型校验（不推荐）
   在tsconfig中关闭strictFunctionTypes配置可消除该错误，但会大幅降低全项目的类型校验严格度，极易引入隐蔽的类型bug，非特殊场景不建议使用。

如果需要定位两个环境的具体差异点，可按以下顺序校验：

• 对比TypeScript版本：多态this的变异性校验逻辑在TS 4.6、4.8、5.0等多个版本都有过调整，版本差异是该问题最常见的诱因。
• 对比RxJS版本：RxJS 6.x对Subject类的方法参数类型标注较宽松，RxJS 7.x收紧了类型定义，会触发泛型不变性校验。
• 校验Angular编译配置：Angular的angularCompilerOptions下的严格模板检查、严格注入检查等配置仅影响模板和DI相关的类型校验，不会干预纯TS代码的基础类型检查，无需调整这部分配置。

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