在 TypeScript 类继承中，若父类构造函数过早调用 this.setup()（而 setup 被子类重写），此时子类字段尚未初始化，this 仅具备父类上下文，导致 this.prop2 为 undefined。根本解法是延迟调用——确保 super() 完成后再执行子类逻辑。
在 typescript 类继承中，若父类构造函数过早调用 `this.setup()`（而 `setup` 被子类重写），此时子类字段尚未初始化，`this` 仅具备父类上下文，导致 `this.prop2` 为 `undefined`。根本解法是延迟调用——确保 `super()` 完成后再执行子类逻辑。
这个问题源于 JavaScript/TypeScript 的对象初始化顺序：子类实例的 this 对象在 super() 调用完成前不会被完全初始化。即使你使用了参数属性（如 public prop2: string），TypeScript 编译器也会将其降级为 this.prop2 = prop2 —— 这行赋值语句严格位于 super() 调用之后。因此，在父类构造函数中同步触发的 this.setup() 实际运行时，prop2 尚未被定义。
下面是一个典型错误示例及其问题剖析：
// ❌ 错误：setup 在 super() 完成前被调用
export abstract class Parent {
constructor(protected readonly parentProp: string) {
if (autoSetup) this.setup(); // ← 此时 this 仅属于 Parent 上下文
}
setup(): void {}
}
export class Child extends Parent {
constructor(prop1: string, public prop2: string) {
super(prop1); // ← prop2 的赋值发生在 super() 返回后！
}
override setup(): void {
console.log(this.prop2); // undefined
}
}? 关键理解：
this是同一个对象引用，但其属性初始化时机由构造函数体顺序决定。super()内部可能执行任意逻辑（包括调用this.setup()），但此时子类字段尚未注入。
✅ 推荐解决方案：将 setup() 调用移至子类构造函数末尾，确保 this 已完全初始化：
export abstract class Parent {
constructor(protected readonly parentProp: string) {}
abstract setup(): void;
}
export class Child extends Parent {
constructor(prop1: string, public prop2: string) {
super(prop1);
// ✅ 此处 super() 已返回，this.prop2 已就绪
if (autoSetup) this.setup();
}
override setup(): void {
console.log(this.prop2); // "prop2" — 正确输出
}
}? 进阶建议：
- 若需统一初始化流程，可引入显式初始化方法（如
init()），避免在构造函数中隐式耦合； - 避免在抽象基类构造函数中直接调用可被重写的方法（即“构造函数中调用虚方法”反模式），这会破坏初始化契约；
- 如必须由父类控制调用时机，可改用模板方法模式 + 延迟执行（例如通过
Promise.resolve().then(() => this.setup())微任务延迟），但语义不如显式调用清晰。
总之，尊重 JavaScript 的初始化顺序是编写健壮继承结构的前提——永远假设子类字段仅在 super() 返回后才可用。
