TypeScript继承带静态工厂方法的抽象类时报TypeError问题

数据老陈

2026-9-1

问题根因

这个错误的本质是跨文件ES模块循环依赖导致的类加载顺序异常，你没察觉到循环依赖，是因为这个依赖环是拆分文件后隐式形成的：
你实际的代码大概率是按类拆分到独立文件的：

A.ts 顶部静态导入了B、C，供静态方法fromValue调用
B.ts 顶部静态导入了A，用来实现class B extends A
C.ts 顶部静态导入了A，用来实现class C extends A
这时候已经形成了A→B→A、A→C→A的依赖环。ES模块遇到静态导入会同步加载对应模块，当测试用例首次导入A时，加载流程如下：

开始执行A.ts，遇到顶部导入B的语句，立刻暂停A的加载，转去执行B.ts
开始执行B.ts，遇到顶部导入A的语句，此时A.ts还卡在第一步加载B的阶段，没有完成类的定义和导出，模块系统给B.ts返回的A值是临时值undefined
B.ts继续执行到class B extends A语句，发现要继承的目标是undefined，直接抛出你看到的错误：

TypeError: Class extends value undefined is not a constructor or null

你把fromValue迁移到独立的AFactory类后问题消失，本质是因为这个改动直接打破了依赖环：A的文件不再需要导入B、C，依赖关系变成B/C单向依赖A、Factory单向依赖A/B/C，不存在环，模块加载顺序自然正常。
如果把三个类全部写在同一个文件里不会触发这个问题——同文件下类按书写顺序初始化，A先完成定义，B和C再执行继承逻辑，此时A已经是合法的构造函数，不会出现undefined的情况。

解决思路

按工程实用性从高到低排序：

方案1：独立工厂类（推荐）
就是你已经验证可行的写法，把实例化逻辑从抽象类中抽离到单独的工厂类，既符合单一职责原则（抽象类只负责定义公共接口，不负责具体子类的实例化逻辑），也从根源上消除了依赖环，是中大型项目里最常用的实现方式。

方案2：子类注册模式
如果不想额外抽工厂类，可以在基类A里维护一个类型和构造函数的映射表，让子类在自身加载完成后主动注册到基类，基类不需要主动导入子类，直接打破依赖环。示例代码：

// A.ts
abstract class A {
  // 存储类型和对应子类构造函数的映射
  private static ctorRegistry = new Map<string, new (p: any) => A & { fromValue: (p: any) => A }>();

  // 提供注册方法给子类调用
  static register(type: string, ctor: new (p: any) => A & { fromValue: (p: any) => A }) {
    this.ctorRegistry.set(type, ctor);
  }

  static fromValue(p: any): A {
    const Ctor = this.ctorRegistry.get(p.type);
    if (!Ctor) throw new Error('invalid parameter');
    return Ctor.fromValue(p);
  }

  abstract doSomething(): string
}

子类定义完成后主动注册即可，不需要改动A的导入逻辑：

// B.ts
class B extends A {
  static fromValue(p: any): B {
    // 实例化逻辑
  }
}
// 注册到基类
A.register('whatever1', B);

C类的实现和注册逻辑和B一致。

方案3：动态导入（不推荐）
把fromValue里对B、C的引用改成动态import()，等模块全部加载完成后再异步加载子类，这种写法会把fromValue变成异步方法，改动成本高，也不符合常规的调用习惯。
不推荐通过调整导入顺序绕开问题，这种方式非常脆弱，后续代码调整很容易再次打破加载顺序触发错误。

内容的提问来源于stack exchange，提问作者Héctor Valls