为何TypeScript的undefined类型与可选属性表现不一致？

这个问题的核心在于TypeScript类型系统严格区分属性的存在性要求和属性值的类型范围，这两种写法本质上表达了完全不同的语义：

1. 基础场景的差异 #

先看你给出的第一个例子：

// 定义1：bar是「允许undefined的必填属性」
interface Foo { bar: number | undefined; }
const foo: Foo = {}; // ❌ 编译失败：缺少bar属性

这里的bar: number | undefined表示：这个属性必须存在于对象中，只是它的值可以是number或者undefined。TypeScript会严格检查对象是否包含这个属性，哪怕你想让它的值是undefined，也必须显式写出来：

const foo: Foo = { bar: undefined }; // ✅ 合法

而可选属性的写法：

// 定义2：bar是「可选属性」
interface Foo { bar?: number; }
const foo: Foo = {}; // ✅ 合法

bar?: number的语义是：这个属性可以不存在于对象中，如果存在的话，它的值是number。TypeScript会自动把这种可选属性的类型推断为number | undefined，同时允许你完全省略这个属性——因为它本身就是可选的。

2. 泛型场景的问题解析 #

再看你的泛型例子：

interface Foo<T = undefined> { bar: T; title: string; }
const foo1: Foo = { title: 'TITLE' }; // ❌ 编译失败

这里默认泛型T是undefined，所以Foo等价于{ bar: undefined; title: string; }——本质上还是「必填属性，值为undefined」，所以你必须显式声明bar: undefined才能通过编译。

你提到用继承解决了这个问题，推测你可能是把bar转为了可选属性，比如：

interface Foo<T = undefined> extends Partial<{ bar: T }> {
  title: string;
}
const foo1: Foo = { title: 'TITLE' }; // ✅ 现在合法了

3. TypeScript的设计原因 #

TypeScript团队之所以做出这样的设计，主要是为了明确语义、避免潜在错误：

• 契约清晰：如果接口定义了一个属性，哪怕它允许undefined，也意味着这个属性是对象契约的一部分，必须存在。比如某些后端API可能期望请求对象包含某个字段，哪怕值是undefined，而不是完全没有这个字段。
• 区分两种不同的业务场景：
  • 当你写bar: number | undefined时，你想表达的是「这个属性必须有，只是值可能未定义」；
  • 当你写bar?: number时，你想表达的是「这个属性可有可无，有则是number类型」。
• 避免隐式行为：如果自动把允许undefined的属性视为可选，会模糊开发者的真实意图，导致一些难以排查的错误——比如开发者本来希望属性必须存在，但因为TypeScript允许省略，不小心漏写了属性，却没有得到编译提示。

4. 如何让泛型默认情况下bar可选？ #

如果你希望在泛型默认值为undefined时，bar是可选的，可以调整接口定义：

interface Foo<T = undefined> {
  bar?: T;
  title: string;
}
// 或者更精确的类型约束
interface Foo<T = undefined> {
  bar: T extends undefined ? undefined | never : T;
  title: string;
}

这样foo1: Foo = { title: 'TITLE' }就能正常通过编译了。

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