在类型体操的题目里，元组元素唯一性校验算是比较能考察递归功力的一类题。它的目标很明确：写一个泛型Unique<T>，当元组中存在重复元素时让类型报错，或者返回一个去重后的元组。很多同学第一次看到答案时会觉得像天书，尤其是里面层层嵌套的条件类型和Exclude的组合。这篇文章就把这个问题拆开揉碎，从最基础的类型转换讲到完整的递归实现，把每一步的推导过程讲清楚。
从元组转联合类型开始理解基础原理
在动手实现唯一性校验之前，必须先理解一个基础操作：如何把元组类型转成联合类型。TypeScript内置的映射行为天然支持这一点，当我们写T[number]时，就得到了元组中所有元素类型组成的联合类型。例如['a', 'b', 'a'][number]的结果就是'a' | 'b'。注意联合类型本身会自动去重，所以同样的字符串字面量只会出现一次，这既是我们后面可以利用的特性，也是需要小心区分的地方。
联合类型的自动去重特性可以帮助我们判断“是否存在重复”，但无法告诉我们“重复出现在哪个位置”。如果只是需要判断整个元组是否有重复，可以先转成联合类型再转回元组长度做比较；但如果要在编译期精确地报告重复位置，就必须走逐项递归比对的路线。两种思路各有适用场景，后面会分别给出实现。
先看一个最小化的判断思路示例：
type ToUnion<T extends readonly unknown[]> = T[number]; // 判断元组去重前后长度是否一致 type HasDuplicate<T extends readonly unknown[]> = UnionToTuple<ToUnion<T>>['length'] extends T['length'] ? false : true; type A = HasDuplicate<['a', 'b', 'c']>; // false，没有重复 type B = HasDuplicate<['a', 'b', 'a']>; // true，存在重复
这段代码的思路是把元组转为联合类型，再把联合类型转回元组（UnionToTuple的实现网上有成熟方案，通过联合类型的分发特性逐一提取成员），比较两个长度。不过UnionToTuple本身实现复杂且依赖分发顺序，只适合做简单的布尔判断，要做精确校验还得靠递归。
递归逐项比对的完整实现
递归方案的核心思想是：取出元组的第一个元素，检查它是否出现在剩余元素中，如果出现就说明有重复，直接返回错误提示类型；否则递归处理剩余部分。这里最关键的技巧是用Exclude从联合类型中排除已检查过的元素。先看判断版本的实现：
type UniqueCheck<T extends readonly unknown[], Seen = never> =
T extends readonly [infer First, ...infer Rest]
? First extends Seen
? '存在重复元素'
: UniqueCheck<Rest, Seen | First>
: true;
type R1 = UniqueCheck<['a', 'b', 'c']>; // true
type R2 = UniqueCheck<['a', 'b', 'a']>; // '存在重复元素'这里的Seen是一个不断累积的联合类型，初始值是never。每次递归时把当前元素用|合并进去，然后用First extends Seen判断当前元素是否已经在已见集合里。需要注意的是，这个判断在First是联合类型时会产生分发行为，可能带来意外结果，比如元组元素本身是'a' | 'b'这种联合类型时，分发的语义需要单独考虑。如果业务场景确定元素都是原子类型，上面的写法就足够了。
如果希望直接得到去重后的元组而不是布尔判断，可以改造为构造版本的实现：
type Unique<T extends readonly unknown[], Seen = never> =
T extends readonly [infer First, ...infer Rest]
? First extends Seen
? Unique<Rest, Seen>
: [First, ...Unique<Rest, Seen | First>]
: [];
type D1 = Unique<['a', 'b', 'a', 'c', 'b']>; // ['a', 'b', 'c']这个版本在遇到重复元素时直接跳过（只递归处理Rest，不把它拼进结果），否则把First拼到结果元组开头。变长元组展开语法[First, ...Unique<Rest>]是整个构造过程的核心，它让类型系统能够像操作数组一样拼接结果。递归终止条件是T不再匹配readonly [infer First, ...infer Rest]，也就是元组已经为空，此时返回空元组[]作为递归的出口。
利用函数参数位置实现硬校验
上面的方案拿到的是一个类型结果，但不会真正让编译器报错。如果想让重复元素直接触发类型错误，最好的办法是借助函数参数位置的校验。构造一个辅助函数，把UniqueCheck的结果与true做对比，不匹配时报错：
declare function assertUnique<
T extends readonly unknown[]
>(
...args: T extends UniqueCheck<T> extends true
? T
: never
) : void;
// 正常编译
assertUnique('a', 'b', 'c');
// 编译报错：Argument of type 'string' is not assignable to parameter of type 'never'
assertUnique('a', 'b', 'a');这个技巧的原理是：当校验不通过时，把参数类型直接置为never，而任何实际值都无法赋给never，于是编译器必然报错。通过剩余参数...args接收展开的元组，再由泛型T推断出实际传入的元素组合，整套校验完全在编译期完成，运行时没有任何开销。如果想给错误信息更好的提示，可以把never换成自定义的错误描述类型，比如'元组中存在重复元素，请检查'，报错信息会更友好。
常见坑点与性能注意事项
第一个常见的坑是递归深度限制。TypeScript的递归类型有实例化深度上限（默认大约50层，视版本而定），当元组长度超过这个限制时会报“Type instantiation is excessively deep”的错误。解决办法有两种：一是改用尾递归风格的写法，TypeScript 4.5之后对尾递归条件类型做了优化，可以处理上千长度的元组；二是采用分治思路，把元组对半拆分分别处理再合并，将递归深度从线性降为对数级别。
第二个坑是联合类型元素的分发问题。前面提到First extends Seen在First本身是联合类型时会触发分发，导致判断结果变成联合类型而不是布尔值。例如元组['a' | 'b', 'a']，第一个元素分发后分别与Seen比较，结果可能是false | '存在重复元素'这种混合体。规避方式是用元组包裹阻止分发：
type UniqueSafe<T extends readonly unknown[], Seen extends readonly unknown[] = []> =
T extends readonly [infer First, ...infer Rest]
? [First] extends [Seen[number]]
? '存在重复元素'
: UniqueSafe<Rest, [...Seen, First]>
: true;这里把Seen改成元组并用[First] extends [Seen[number]]的形式比较，包裹的元组阻止了条件类型的分发，语义更加可控。第三个需要注意的点是never元素的特殊性，如果元组里可能包含never类型，First extends Seen在First为never时结果永远是never，处理逻辑会走不到预期分支，需要额外用[First] extends [never] ? ...提前拦截。
总的来说，元组唯一性校验这道题串起了条件类型分发、变长元组推断、递归终止设计、递归深度优化等多个知识点。掌握它之后再去看其他类型体操题目，比如Combination、Subsequence，会发现解题套路是相通的：几乎都是“取出头部、处理、拼接尾部、空元组出口”这套模板的变体。建议自己在编辑器里把上面的代码逐段敲一遍，用类型悬浮提示观察每一步的推导结果，比只看文章理解要深刻得多。
TypeScript元组类型类型体操修改时间：2026-09-05 00:52:49