TypeScript中interface与type扩展Record类型结果差异原因

以下是问题复现代码：

interface InterfaceObject {
    a: number;
}
type TypeObject = {
    a: number;
}
type InterfaceObjectTest = InterfaceObject extends Record<string | symbol | number, unknown> ? true : false; // false
type TypeObjectTest = TypeObject extends Record<string | symbol | number, unknown> ? true : false; // true

核心差异来源 #

这个结果不是语法bug，是TypeScript类型系统对两种类型声明的隐式索引签名校验规则不同导致的：

• 首先明确Record<string | symbol | number, unknown>的本质是带全域索引签名的类型，要求所有合法键（string/number/symbol）对应的值都必须是unknown类型。
• 用type定义的对象字面量类型是封闭的，声明完成后结构就固定，TS可以静态遍历到它的所有属性，因此在匹配值为顶层类型（unknown/any）的索引签名时会做隐式兼容：只要现有属性的类型都属于unknown（所有类型都满足该条件），就判定extends关系成立。
• 用interface声明的类型是开放的，支持声明合并，TS无法在检查阶段确定这个interface后续会不会被补充其他属性，因此不会默认给它加隐式索引签名兼容，必须显式声明匹配的索引签名，才会判定extends关系成立。

替换Record值类型后结果一致的原因 #

当你把Record值位置的unknown换成具体类型（比如number/string）时，TS会走常规的结构化类型检查逻辑，不再触发顶层类型对应的特殊隐式索引签名规则：

• 此时只要目标类型的所有已知属性类型都符合Record的要求，且没有冲突属性，不管是type还是interface声明的类型，都会判定extends成立。比如例子里的InterfaceObject只有a: number属性，完全满足Record<string, number>的约束，因此判断结果为true。

验证方式 #

如果给interface显式加上匹配的索引签名，它的判断结果就会和type完全一致：

interface IndexedInterfaceObject {
    a: number;
    [key: string | symbol | number]: unknown;
}
type IndexedInterfaceTest = IndexedInterfaceObject extends Record<string | symbol | number, unknown> ? true : false; // true

这个行为是TS团队刻意保留的设计，目的是规避interface声明合并带来的类型安全漏洞，不是两种类型的底层结构存在本质区别。

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