TS泛型中为何{id: P['id']} & Omit<P,'id'>无法赋值给类型P？

{ id: P['id'] } & Omit<P, 'id'> 无法赋值给泛型P的报错不是TS推导bug，本质是TS泛型系统的保守安全设计，直觉上的「拆分再合并等价于原类型」的恒等关系在TS泛型检查中不成立。 #

根本原因 #

1. 泛型子类型存在不可预知的结构约束 #

P extends Base仅给P设置了最基础的上界：必须包含id: string属性，但没有限制P的其他结构。P可以被实例化为任意Base的子类型，包括但不限于：

• 带字面量类型约束的类型
• 带私有类型标记（品牌类型）的类型
• 由条件类型、映射类型生成的动态结构类型
• 类实例类型
  在泛型函数执行、P被具体类型实例化之前，TS无法证明拆分后重组的对象能满足所有可能的P子类型的全部约束。
  举个真实会出现类型漏洞的场景：

// 模块内部定义的唯一symbol，用于给类型打品牌标记，不会导出
const internalBrand = Symbol('internal_brand')
interface InternalEntity extends Base {
  id: string
  name: string
  [internalBrand]: true // 该属性是类型必填项，但外部模块无法访问symbol，不可能构造出这个属性
}

如果TS允许拆分重组的对象直接赋值给P，就会出现传入的对象缺少必填品牌属性的类型漏洞，这类风险是TS静态检查阶段必须拦截的。
报错提示本身也明确说明了逻辑：重组后的类型满足P的上界Base的约束，但P可以被实例化为和Base约束结构不同的子类型，因此不能直接赋值。

2. TS不做高阶类型等价性证明 #

从类型理论角度，证明「拆分id再合并剩余属性等价于原泛型P」属于高阶定理证明范畴，这类推导的时间成本会随类型复杂度指数上升。TS作为生产环境用的编译器，为了保证编译性能，放弃了这类复杂推导：在泛型未实例化的阶段，TS不会对对象展开、交叉类型合并的结果做和原泛型的等价性校验，只会保守判定为类型不兼容。 #

处理方案 #

如果业务逻辑上能确定重组后的对象完全符合P的结构要求，可以使用类型断言绕开检查，这也是这类泛型场景的通用处理方式：

function main <P extends Base>({ id, rest, check }: Foo<P>): void {
  check({
      id,
      ...rest
  } as P)
}

如果不希望使用硬断言，也可以调整Foo的类型定义，避免直接拆分泛型P的结构，但会损失一部分类型便利性，绝大多数场景下上述断言是安全的。 #

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