TypeScript 类型体操：如何精准控制可选参数的“去留”

作者火车叼位

2026年2月26日 14:15

在 TypeScript 的日常开发中，我们经常为了灵活性而将接口（Interface）或类型（Type）的属性定义为可选（使用 ? 修饰符）。但在某些特定场景下，例如配置初始化完成、表单提交前验证或 API 响应处理后，我们需要确保这些属性已经存在，即将其转换为“必选”状态。

这种转换不仅能提供更好的代码提示，还能在编译阶段规避大量的 null 或 undefined 检查。本文将由浅入深介绍四种主流的转换方案。

1. 全局转换：使用内置工具类型 `Required<T>`

TypeScript 自 2.8 版本起引入了 Required<T>，这是最直接的方案。它会遍历类型 T 的所有属性，并移除每个属性末尾的可选修饰符。

interface UserProfile {
  id: string;
  name?: string;
  email?: string;
}

// 转换后：id, name, email 全部变为必选
type StrictUser = Required<UserProfile>;

const user: StrictUser = {
  id: "001",
  name: "张三",
  email: "zhangsan@example.com" // 缺少任何一个都会报错
};

适用场景：当你需要对整个对象进行“严格化”处理时，这是首选方案。

2. 精准打击：仅转换特定属性为必选

在实际业务中，我们往往只需要确保某几个关键字段存在，而保留其他字段的可选性。这时可以结合 Pick、Omit 和 Required 构建一个复合工具类型。

我们可以定义一个通用的 MarkRequired 类型：

/**
 * T: 原类型
 * K: 需要转为必选的键名联合类型
 */
type MarkRequired<T, K extends keyof T> = 
  Omit<T, K> & Required<Pick<T, K>>;

interface Config {
  host?: string;
  port?: number;
  protocol?: 'http' | 'https';
}

// 示例：仅让 host 变为必选，port 和 protocol 依然可选
type EssentialConfig = MarkRequired<Config, 'host'>;

const myConfig: EssentialConfig = {
  host: "localhost" // port 和 protocol 可选填
};

原理解析：该方法先用 Omit 剔除目标属性，再用 Pick 选出目标属性并通过 Required 转为必选，最后通过交叉类型 & 进行合并。

3. 深入底层：使用映射类型中的 `-?` 符号

如果你正在尝试编写自己的类型库，了解映射类型（Mapped Types）的修饰符至关重要。在 TypeScript 中，+ 和 - 可以作为前缀应用于 ? 或 readonly 修饰符。

type MyRequired<T> = {
  // -? 表示显式地移除可选属性标记
  [P in keyof T]-?: T[P];
};

// 与此相对，+?（通常简写为 ?）用于增加可选标记
type MyPartial<T> = {
  [P in keyof T]+?: T[P];
};

技术要点：使用 -? 是 Required<T> 的底层实现原理。它不仅能去除问号，在处理一些复杂的条件类型映射时，这种手动控制的能力非常强大。

4. 函数参数与深度嵌套处理

函数参数转换

对于函数，最稳妥的方法是在重载或重新定义时直接移除 ?。但在高阶函数或泛型约束中，如果你想约束传入的函数必须接受必选参数，可以利用上述类型工具。

深度嵌套（Deep Required）

内置的 Required 只能处理第一层属性。如果对象是深层嵌套的，你需要递归处理：

type DeepRequired<T> = {
  [P in keyof T]-?: T[P] extends object 
    ? DeepRequired<T[P]> 
    : T[P];
};

interface NestedConfig {
  db?: {
    user?: string;
    pwd?: string;
  }
}

type StrictNested = DeepRequired<NestedConfig>;

建议：在处理极其复杂的深层转换时，推荐使用社区成熟的库如 ts-essentials，其 DeepRequired 经过了大量边缘情况的验证。

结论与行动建议

根据不同的工程需求，建议采取以下策略：

立即可做：检查项目中的配置对象或 API 聚合层，使用 Required<T> 替代繁琐的非空断言（!）。
最佳实践：为了保持代码的 DRY（Don't Repeat Yourself）原则，建议在项目的 types/utils.d.ts 中收藏 MarkRequired 工具类型，用于处理部分属性必选的场景。
注意性能：过度使用复杂的递归类型（如 DeepRequired）可能会增加 TypeScript 编译器的负担，在大型项目中应谨慎评估其影响范围。

普通视图

1. 全局转换：使用内置工具类型 Required<T>