静态方法中this指向调用类而非实例，只能访问静态成员；正确用法包括new this()实现多态创建、避免调用实例方法；TypeScript中可用this类型约束确保类型安全。
在父类静态方法里写 this，本身就会出问题——因为静态方法中 this 指向的是调用它的那个类（比如 Parent.fn() 中 this 是 Parent，Child.fn() 中 this 是 Child），但它**不是当前实例**，也不参与原型链继承。所谓“子类继承时引用错位”，本质是误把静态方法当实例方法用，或混淆了 this 在不同上下文中的含义。
静态方法里不要依赖实例状态
静态方法属于类本身，不依赖任何实例。如果它内部用了 this.xxx，那访问的只能是该类自身的静态属性或方法，不能读写实例字段（如 this.name）。
- ✅ 正确：访问静态成员 ——
static fn() { console.log(this._VERSION); } - ❌ 错误：试图访问实例属性 ——
static fn() { return this.name; }（this.name不存在，运行时为undefined或报错）
别让子类误以为静态方法能返回实例
常见陷阱是写一个静态方法，想让它“创建并返回当前类的实例”，但忘了 this 在静态方法中就是构造函数本身，必须用 new this() 才能生成实例。
- ✅ 安全写法：
static create() { return new this(); }—— 子类调用Child.create()得到的是Child实例 - ⚠️ 风险写法：
static create() { return new Parent(); }—— 无论谁调用，都只返回Parent实例，破坏多态
避免在静态方法中调用实例方法
静态方法不能直接调用 this.prototype.xxx 或 this.prototype.constructor.xxx，更不能用 super（super 只在实例方法和构造器中有效）。
- ❌ 错误：
static init() { this.prototype.sayHello(); }（prototype是对象，不是函数上下文） - ✅ 替代思路：把逻辑拆出来，让静态方法只负责构造，再由实例方法承接行为 ——
static build() { return new this().init(); }
类型系统里显式约束 this 类型（TypeScript 场景）
如果用 TypeScript，可以在静态方法签名中用 this: typeof SomeClass 或泛型 <t extends typeof parent>(this: T)</t> 来约束调用者类型，防止传入不兼容的子类。
- 例如：
static main<t extends typeof parent>(this: T, props?: any): InstanceType<t> { return new this() as InstanceType<t>; }</t></t></t> - 这样
Child.main()的返回值类型就是Child，而非宽泛的Parent
