为什么含条件定义属性的TypeScript联合类型会比预期更宽松？

你遇到的现象不是TypeScript的推导bug，本质是对TS结构类型系统的几个核心设计存在认知偏差： #

1. {}类型根本不是「无任何属性的空对象」 #

这是最常见的误区。TS里的{}是顶层类型，语义是所有非null/undefined的值，数字、字符串、带任意属性的对象都可以合法赋值给{}。
你给出的第一份代码：

const test = Math.random() < 0.5 ? { a: 1, b: 2 } : {};

如果你预期的推导结果是{ a: number; b: number } | {}，这个类型本身是无效的：因为{a:number; b:number}是{}的子类型，联合类型会被直接折叠成{}，完全丢失真分支的属性信息。TS为了保留分支的类型信息，会自动把两个联合分支的属性对齐：空对象分支不存在a、b属性，访问时会返回undefined，因此被推导为a?: undefined; b?: undefined的结构。

TS的结构类型系统不建模「对象运行时物理上是否存在某个属性键」，只关心「访问该属性时得到的返回值类型」。对空对象{}来说，访问a属性的返回值就是undefined，这个推导结果完全符合TS的规则。

2. 默认规则下TS不区分「属性不存在」和「属性存在且值为undefined」 #

JavaScript原生语义里，这两种场景在绝大多数操作下表现完全一致：

const noProp = {};
const undefinedProp = { items: undefined };
console.log(noProp.items === undefinedProp.items); // 输出true，值完全相等
// 只有用in操作符判断时才有区别
console.log('items' in noProp); // false
console.log('items' in undefinedProp); // true

TS默认不会为了建模这种极少用到的差异，大幅提升类型标注的复杂度。因此普通的可选属性items?: T，默认允许三种情况：

• items属性不存在于对象上
• items属性存在，值为类型T
• items属性存在，值为undefined
  你给出的第二个示例：
  
  里面items属性被推导为可以赋值undefined，就是这个默认规则的体现。如果需要严格禁止「可选属性存在且值为undefined」的情况，可以在tsconfig中开启exactOptionalPropertyTypes配置，开启后可选属性的语义会收紧为「要么属性不存在，要么属性值为合法的T类型」，不允许显式给可选属性赋值undefined。

几个实用的补充说明 #

• 不要用{}表示严格空对象，如果需要约束对象不能有任何自有属性，使用Record<PropertyKey, never>类型。
• TS的类型系统不是100%健全的，设计上始终在类型检查精度、使用成本、开发体验之间做权衡，从来没有承诺过完全精确映射所有JavaScript运行时行为。
• 多余属性检查（Excess Property Check）只在对象字面量直接赋值的场景触发，不是通用的类型安全保证，不要依赖它做严格的属性存在性校验。

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