为何两个看似等价的TypeScript映射元组类型不相等？

两类类型的实际结构差异 #

在TypeScript中悬浮查看两个类型的实际定义，可以直观看到明确差异：

• WrappedNumbers2 最终是和原元组结构完全一致的固定长度元组，类型为 [{ key: number }, { key: number }, { key: number }]。它完全保留了原元组的长度约束、可解构、索引访问的元组特性，没有额外映射数组内置的属性和方法。
• WrappedNumbers1 最终是一个普通对象类型。它会遍历原元组的所有可访问键，包括数字索引0/1/2、固定的length: 3属性、所有从Array继承的内置方法（push/pop/toString等），每个键对应的值为{ key: 原键的类型 }。这个类型本身不具备元组的类型特性，无法作为元组参与解构操作，也没有固定长度的类型约束。

差异的核心来源 #

二者不等确实由类型实例化路径差异直接导致，本质是TypeScript对两类映射类型的解析逻辑不统一：

1. 直接映射具体元组的处理逻辑
   当你直接书写{ [K in keyof NumbersTuple]: { key: NumbersTuple[K] } }时，TS在类型解析阶段会触发针对具体元组的特殊优化：识别到源类型是明确的元组结构，就会按照元组的元素定义逐位做映射，全程保留元组的类型身份，不会去遍历元组继承自Array的内置成员，最终输出结构完全匹配的元组类型。
2. 泛型映射类型的实例化逻辑
   当你把映射逻辑封装为泛型WrapKey<T>，再将NumbersTuple作为类型参数传入时，TS在泛型实例化阶段走的是通用映射类型的处理逻辑：只会按照keyof T的全量键集合做遍历映射，不会触发上面那个针对具体元组的特殊优化。这个过程会把元组所有的可枚举键（包括Array内置成员）都做映射处理，最终生成普通对象结构，丢失了元组的所有特性。

补充说明 #

这个行为差异是TypeScript历史设计的逻辑遗留：早期映射类型是为普通对象设计的，后续版本才逐步加入对元组/数组的映射支持，针对具体类型的元组映射优化没有同步对齐到泛型实例化的通用路径中。如果需要让泛型包装后的类型和直接映射的结果一致，需要手动针对元组/数组结构做递归类型处理，匹配TS的元组解析逻辑。

可对齐行为的泛型实现示例：

type WrapKey<T> = T extends readonly [infer First, ...infer Rest]
  ? [{ key: First }, ...WrapKey<Rest>]
  : T extends readonly unknown[]
  ? { key: T[number] }[]
  : { [K in keyof T]: { key: T[K] } };

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