为何TypeScript无法简化数组类型相关的交叉类型？

先看可正常工作的场景：当联合类型的判别式为字符串字面量时，交叉类型能正确完成类型收窄：

type Post = {type: "post", body: string}
type User = {type: "user", name: string}
type Entity = Post | User

// 成功收窄为Post类型
type PostAgain = Entity & {type: "post"}
// 成功收窄为User类型
type UserAgain = Entity & {type: "user"}

const post: PostAgain = getPost()
const body = post.body // 可正常识别body字段

但当判别式换成数组字面量时，交叉类型的收窄逻辑失效：

type Post = {type: ["post"], body: string}
type User = {type: ["user"], name: string}
type Entity = Post | User

// 无法按预期收窄为Post
type PostAgain = Entity & {type: ["post"]}
// 无法按预期收窄为User
type UserAgain = Entity & {type: ["user"]}

const post: PostAgain = getPost()
const body = post.body // 报错：找不到body属性

核心原因分析 #

1. 字符串字面量与数组字面量的类型本质差异 #

字符串字面量（如"post"）是单例类型，仅代表唯一的一个值，TypeScript能精准匹配联合类型中对应分支的结构。

而数组字面量["post"]默认对应的类型是string[]，即便添加readonly修饰成readonly ["post"]，它依然是元组类型——表示“包含指定元素序列的数组”，而非仅代表唯一值的单例类型。TypeScript无法认定{type: ["post"]}和Post中的type是完全等价的结构，因为理论上存在如["post", "extra"]这类满足{type: ["post"]}约束，但不属于Post的结构（尽管你的联合类型中没有定义这类分支，但TypeScript的结构化类型系统会考虑这种可能性）。

2. 结构化类型系统的约束 #

TypeScript采用结构化类型系统，类型匹配依赖结构而非名称。对于对象类型，结构一致即可判定为同一类型，但数组/元组的结构匹配规则更宽松：

• readonly ["post"]和["post"]结构兼容但并非完全相等；
• 当执行Entity & {type: ["post"]}时，TypeScript只会推导type字段为["post"]（因为User["type"]与["post"]交叉为never），但不会主动关联到Post类型——结构化类型系统不会自动推断“该交叉类型只能是Post”，除非显式声明。

3. 实现优先级与成本问题 #

该问题本质是TypeScript对元组字面量作为判别式的支持不足。虽然从业务逻辑看Entity & {type: ["post"]}只能是Post，但要让类型检查器自动识别这一点，需要修改现有类型收窄逻辑，增加对元组字面量的精确匹配规则，开发成本较高。而目前TypeScript团队的优先级更偏向于更常用的特性优化，这类场景的需求普遍性相对较低，因此暂未实现。

临时解决方案 #

如果需要用数组作为判别式，可通过as const将元组转为只读字面量，再用Extract工具类型替代交叉类型完成收窄：

type Post = {type: ["post"] as const, body: string}
type User = {type: ["user"] as const, name: string}
type Entity = Post | User

// 使用Extract工具类型精准收窄
type PostAgain = Extract<Entity, {type: ["post"]}>
const post: PostAgain = getPost()
const body = post.body // 可正常识别body字段

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