TypeScript 判断类型是否兼容并不是看类有没有 implements 某个接口，而是看具体的形状是否对得上。这个规则在实例成员身上很直观，一旦涉及到构造函数签名，就容易出现违反直觉的报错：接口里明明声明了 new 签名，类也写了对应构造函数，为什么 implements 还是失败？要回答这个问题，需要先拆开类的实例侧和静态侧。
在很多强类型语言中，接口可以同时约束实例成员和构造函数，但 TypeScript 的接口只描述值的形状。类作为类型使用时表示实例，而类作为值使用时才有静态侧。构造函数、静态属性和静态方法都挂载在类值上，它们不属于实例类型。
一、实例侧和静态侧在类型层面如何区分
在 TypeScript 中，类名出现在类型位置时指实例类型。例如 Clock 类型只包含 currentTime 和 tick()，并不包含 constructor。要想拿到类值本身的类型，需要使用 typeof Clock。这个类型包含构造函数签名以及所有静态成员。也就是说，同一个类有两个相关但不同的形状：一个是 new 出来的对象，另一个是类对象自身。
接口可以描述任意对象形状，因此它既可以描述实例侧，也可以描述静态侧。描述实例侧时使用普通成员，描述静态侧时使用 new (参数): 返回类型 这种构造签名。比如 ClockConstructor 接口描述的是一个可 new 的函数，而不是某个 new 出来的实例。如果不理解这一层，就会把 implements ClockConstructor 当成验证构造函数，而 TypeScript 并不会执行这种验证。
interface ClockInterface {
currentTime: Date;
tick(): void;
}
interface ClockConstructor {
new (hour: number, minute: number): ClockInterface;
}
class Clock implements ClockInterface {
currentTime: Date = new Date();
constructor(hour: number, minute: number) {
this.currentTime = new Date();
}
tick() {
console.log('tick');
}
}
class WrongClock implements ClockConstructor {
// Error: Class 'WrongClock' incorrectly implements interface 'ClockConstructor'.
// Type 'WrongClock' provides no match for the signature 'new (hour: number, minute: number): ClockInterface'.
}
这里的 Clock 类实现 ClockInterface 没有问题，因为实例确实有 currentTime 和 tick。但如果改成 implements ClockConstructor，编译器会在类名处直接提示实例侧缺少构造签名，因为接口要求 new 返回 ClockInterface，而这个要求被错误地放到实例类型上检查。
二、构造签名接口与类的赋值兼容性
虽然类不能用 implements 实现带 new 签名的接口，但类对象本身完全可以赋值给这个接口类型。下面的代码是合法的：
const ctor: ClockConstructor = Clock;
function createClock(
ctor: ClockConstructor,
hour: number,
minute: number
): ClockInterface {
return new ctor(hour, minute);
}
const clock = createClock(Clock, 12, 30);
这里编译器会把 Clock 作为值处理，取其 typeof Clock 静态类型。它的构造函数签名是 new (hour: number, minute: number) => Clock。目标接口要求 new (hour: number, minute: number) => ClockInterface，参数一致，返回值 Clock 可以赋值给 ClockInterface，于是整个构造签名匹配成功。
这种赋值检查才是 TypeScript 类型兼容性的核心：源类型只要拥有目标类型要求的全部成员，且成员类型兼容，就视为可赋值。类的静态侧包含构造函数签名和静态属性，因此也能像普通对象一样参与结构化比较。工厂函数 createClock 能接收任何符合 ClockConstructor 形状的类或构造函数，而不必关心它是否显式 implements 过某个接口。
所以错误用法 class WrongClock implements ClockConstructor 并不是静态侧赋值，而是把 ClockConstructor 当成了实例接口。真正的静态侧匹配发生在变量赋值、函数传参、类型断言等场景中。
三、构造签名参数与返回值如何影响兼容性
构造函数签名本质上是一种函数类型，所以它的参数和返回值也遵循函数类型兼容规则。在 TypeScript 开启 strictFunctionTypes 时，函数类型参数按逆变检查，返回值按协变检查。构造签名同样如此。理解这一点能避免在工厂函数中出现隐藏的类型错误。
假设有两个动物类构造器：
interface Animal {
name: string;
}
interface Dog extends Animal {
bark(): void;
}
interface AnimalConstructor {
new (animal: Animal): Animal;
}
interface DogConstructor {
new (dog: Dog): Dog;
}
declare const animalCtor: AnimalConstructor;
declare const dogCtor: DogConstructor;
// 开启 strictFunctionTypes 时，以下赋值不兼容
const ctor1: AnimalConstructor = dogCtor; // 参数 Dog 比 Animal 窄
const ctor2: DogConstructor = animalCtor; // 返回 Animal 比 Dog 宽
为什么第一个赋值不允许？目标类型 AnimalConstructor 表示调用方可能传入任意 Animal，但 dogCtor 只能接收 Dog，如果允许赋值，运行时就可能把一只普通 Animal 传给只接受 Dog 的构造器。第二个赋值不允许则是因为目标要求返回 Dog，但源返回 Animal，调用方拿到的对象可能缺少 bark 方法。逆变与协变分别从参数和返回值两侧保护了这个边界。
如果关闭 strictFunctionTypes，函数参数兼容会变得更宽松，但现代 TypeScript 项目通常建议开启该选项，以便在工厂函数、依赖注入容器等泛型上下文中获得更可靠的构造函数类型推导。
四、用抽象构造签名和类型断言处理更复杂的静态侧
除了普通构造签名，TypeScript 还提供了 abstract new (...args: any[]) => T 形式的抽象构造签名，用来表示一个抽象类类型而不是具体类类型。这在需要约束调用方只能传入抽象类时很有用。比如你想声明一个服务构造器，要求它不仅能 new，还带一个静态 displayName：
interface Service {
run(): void;
}
interface AbstractServiceConstructor {
new (...args: any[]): Service;
displayName: string;
}
class UserService implements Service {
static displayName = 'UserService';
run() {
console.log('user service');
}
}
const ctor: AbstractServiceConstructor = UserService;
这里 AbstractServiceConstructor 同时描述了构造函数签名和静态属性 displayName。由于 UserService 的静态侧拥有 displayName，并且构造函数返回实例兼容 Service，整个类值可以赋值给该接口。这种写法在依赖注入、插件系统、命令注册表等场景中非常常见，本质上还是结构化类型兼容性在静态侧的应用。
如果类确实需要 implements 一个带构造签名的接口，可以考虑拆成两个接口：一个描述实例成员，另一个描述构造签名，然后让类只实现实例接口，再通过单独的工厂函数或类型变量处理构造器。也可以使用类型断言暂时绕过，但更推荐让类型系统自然推导静态侧，而不是用 assertion 掩盖不合理的接口设计。
TypeScript类型兼容性构造函数签名类静态侧修改时间：2026-10-02 20:16:52