TypeScript中接口可选属性传入非可选构造函数的行为疑问

在开发TypeScript项目时，遇到了一个特殊行为：即便构造函数期望非可选的参数类型，传入接口的可选属性（可能为undefined）时，TypeScript并未抛出警告或错误。示例代码如下：

// StartPaymentReq Interface
export interface StartPaymentReq {
  email?: string;
}

// Payment Class
export class Payment {
  email: string;

  constructor(email: string) {
    this.email = email;
  }
}

// Inside some function or method
const { email }: StartPaymentReq = req.body; // email被推断为`string | undefined`
const payment = new Payment(email); // 无TypeScript警告或错误，即便email可能是undefined

预期行为：由于Payment类的email属性是非可选的，TypeScript应该在传入可能为undefined的参数时抛出警告或错误。

实际行为：构造函数期望非可选的string类型参数，但传入可能为undefined的email时，TypeScript未给出任何提示。

1. 这是TypeScript的有意设计行为吗？ #

是的，这是TypeScript的有意设计，核心原因在于编译配置的差异：

• 在默认的非严格模式下，TypeScript会将undefined和null视为可兼容任意类型的值，所以不会对这类场景报错，目的是兼容早期无类型约束的JavaScript代码。
• 当你开启strictNullChecks编译选项（属于strict模式的子集）后，TypeScript会强制校验null/undefined的类型兼容性，此时传入string | undefined给期望string的参数就会立刻抛出错误。

2. TypeScript应该在此类场景抛出警告或错误吗？ #

这取决于你的类型安全需求：

• 从严谨的类型检查角度，应该开启strictNullChecks，让编译器在开发阶段就拦截这类潜在的运行时错误，这也是TypeScript推荐的最佳实践。
• 若维持默认非严格模式，TypeScript会放宽检查，不会主动报错，但这会埋下运行时崩溃的风险。

3. 构造非可选参数对象时，处理可选属性的最佳实践？ #

推荐以下几种可靠的处理方式：

• 开启严格模式：在tsconfig.json中设置"strict": true（包含strictNullChecks），从根源上强制类型校验，让编译器直接报错，避免手动遗漏检查。
• 手动校验并兜底：在传入构造函数前，检查参数是否存在，不存在则抛出错误或提供默认值：

  const { email }: StartPaymentReq = req.body;
  if (!email) {
    throw new Error("创建Payment实例必须传入email");
    // 或提供默认值：const safeEmail = email || "default@example.com";
  }
  const payment = new Payment(email);
  

• 使用类型守卫（推荐）：自定义类型守卫确保参数符合必填要求，既保留类型安全，又能清晰处理非法输入：

  function isPaymentRequestValid(req: any): req is { email: string } {
    return typeof req.email === "string" && req.email.trim().length > 0;
  }
  
  if (!isPaymentRequestValid(req.body)) {
    throw new Error("支付请求不合法：email为必填项");
  }
  const { email } = req.body;
  const payment = new Payment(email);
  

• 谨慎使用类型断言：如果你100%确认参数不会是undefined，可以用类型断言跳过检查，但这种方式会丢失类型校验，仅适用于逻辑绝对确定的场景：

  const payment = new Payment(email as string);
  

内容的提问来源于stack exchange，提问作者János