不正确和不直观
不直观，是的;没有我们能做得那么好，是的;但“不正确”多少有些争议。（顺便说一句，这个问题引发了一场关于never[]在概念上是否与[]相同的讨论，尽管它们在可赋值性上存在特定的差异。）无论如何，由于never[]不能赋值给[]，因此这是一个很好的论据，可以证明T1是“不正确的，但是(3 | 1 | 2)[]显然是[1, 2, 3]的有效表示;只是不太好😄
出于好奇，既然有4👍个关于一个似乎有些神秘的问题，这是在实践中出现的地方？

自从TS 4.1终于添加了递归条件类型别名之后，我一直在构建类型级编程库。但是几个小时后，我遇到了这个问题，并在twitter上和其他人聊了几天。这👍似乎是我认识的人添加的，或者和我讨论过这个问题。

我同意T1的说法是正确的，很抱歉用错了词。但是，我想我们都同意（3| 2个|1）此时[]不是一个正确或有用的类型，因为一些重要信息被丢弃，它可能会导致一些意外的问题。🙂
（抱歉格式松散，我用移动的写了这篇评论...）

自从TS 4.1终于添加了递归条件类型别名之后，我一直在构建类型级编程库。但是几个小时后，我遇到了这个问题，并在twitter上和其他人聊了几天。这👍似乎是我认识的人添加的，或者和我讨论过这个问题。
我也有类似的情况。我试图Map嵌套的元组类型。

这也会变成数组型别，即使交集的两边都是以Tuple开始：

type X = [...[1, 2] & [1, 2 | 3]]
//   ^? type X = (2 | 1)[]

其实这也是坏的[...[1] & [unknown]]
当我试图从用其他属性扩充的元组中获取元组时，也遇到了类似的“问题”。
通过调查，我发现即使是[...([1,2,3] & unknown[])]也是有损耗的。
你会发现我在取回元组方面的不同尝试。显式地迭代数字键有效，但我很惊讶我不得不走这么远。

type A = [1,2,3] & { foo: unknown };

// -> (3 | 1 | 2)[]
type B = [...A]

// -> { [x: number]: 3 | 1 | 2 }
type C = { [K in keyof A as K extends number ? K : never]: A[K] }

// -> [2 | 1 | 3]
type D = CloneTuple<A>

type CloneTuple<T extends unknown[], R extends unknown[]=[]> =
    T extends [infer A, ...infer Rest]
    ? CloneTuple<Rest, [...R, A]>
    : R

// -> [1, 2, 3]
type E = ToTuple<A>

type ToTuple<
    T extends unknown[],
    L extends number=T['length'],
    C extends number = 0,
    R extends unknown[]=[]
> = C extends L ? R : ToTuple<
    T,
    L,
    [1,2,3,4,5,6,7,8,9,10][C],
    [...R, T[C]]
>