TypeScript合并对象可选属性类型推断异常：是特性还是Bug？

你遇到的这个情况是TypeScript的有意设计行为，并非Bug，核心原因在于TypeScript对可选属性和对象展开的类型推断逻辑：

1. 可选属性的乐观类型推断 #

TypeScript中，bar?: string等价于bar: string | undefined，但在处理对象展开时，TypeScript会做乐观推断——它默认认为如果调用者传入了bar属性，其值必然是string类型，而非显式传入undefined。这种设计是为了平衡类型严谨性和开发体验，避免对所有可选属性都强制添加undefined检查。

在你的代码中，defaultOptions的bar是确定的"abc"，而options的bar是可选的string | undefined，TypeScript合并后推断的类型是{foo: number; bar: string}，完全忽略了bar被显式设为undefined的可能性。

2. satisfies关键字的检查逻辑 #

satisfies的作用是验证右侧表达式的类型是否可赋值给目标类型。由于TypeScript已经乐观推断出fullOptions的类型是{foo: number; bar: string}，而这个类型完全符合Required<Options>（{foo: number; bar: string}）的要求，因此不会触发报错。

3. 运行时错误的根源 #

当你调用f({foo: 456, bar: undefined})时，运行时undefined会覆盖defaultOptions中的"abc"，但TypeScript的类型系统无法捕捉到这种显式传入undefined的场景——它不会主动将可选属性的显式undefined赋值纳入类型检查范围。

解决方案 #

要避免这类运行时错误，你可以通过以下方式优化代码：

• 明确禁止属性为undefined：调整类型定义，区分“可选（不传入）”和“允许传入undefined”：

  interface Options {
    foo?: number; // 不传入该属性时使用默认值
    bar?: Exclude<string, undefined>; // 禁止传入undefined，只能不传或传string
  }
  

• 添加运行时类型守卫：在使用属性前检查是否为undefined：

  function f(options: Options) {
    const fullOptions = {
      ...defaultOptions,
      ...options,
    };
    if (fullOptions.bar === undefined) {
      throw new Error("bar 不能为 undefined");
    }
    return fullOptions.bar.toUpperCase();
  }
  

• 使用工具类型强制必填：如果要求调用者必须传入所有属性（或明确设置默认值覆盖），可以直接使用Required<Options>作为函数参数类型。

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