除自定义泛型外，TypeScript中是否有更优方式为类型添加null/undefined？

在TypeScript中，当方法的多个参数允许为null或undefined时，直接写T | null | undefined会让方法签名冗长：

doThing(
  user: User | undefined | null, 
  thing: Thing | undefined | null, 
  ...moreArgs
): Result {
  // ...
}

你提到的两种方案确实存在明显弊端：

• 可选参数（?）仅适用于参数真正可选的场景，强行用user?: User | null会混淆「参数可省略」和「参数值可空」的语义，逻辑上不合理。
• 自定义泛型如Nullable<T>虽能简化签名，但大型项目中容易出现Maybe<T>、Nullable<T>等同类重复定义，来自自定义或三方库，难以统一。

针对这个问题，有几个更统一的优化方向：

1. 全局统一可空类型定义+规范约束 #

在项目根目录的公共类型文件（如src/types/global.ts）中定义唯一的可空类型：

// 统一命名，比如约定用Maybe或Nullable，项目内强制遵循
type Maybe<T> = T | null | undefined;

然后通过以下方式确保全局可用并避免重复定义：

• 在tsconfig.json中配置compilerOptions.types，将该文件纳入全局类型，无需每次手动导入；
• 用ESLint规则（如自定义规则或@typescript-eslint/no-type-alias配合白名单）禁止项目内自定义其他同类可空类型；
• 针对三方库的同类类型（如fp-ts的Option<T>），封装转换工具函数，将其转为项目统一的Maybe<T>后再使用。

2. 用接口封装参数 #

将多个可空参数封装到一个接口中，既能简化方法签名，也便于统一管理参数类型：

interface DoThingParams {
  user: Maybe<User>;
  thing: Maybe<Thing>;
  // 定义其他参数
}

function doThing({ user, thing, ...moreArgs }: DoThingParams): Result {
  // ...
}

这种方式还能方便后续扩展参数，同时让参数语义更清晰。

3. 结合类型断言与工具函数（可选） #

如果某些场景下需要频繁处理可空值，可以封装工具函数统一处理空值逻辑，同时配合类型断言简化签名：

function withNullable<T>(value: T | null | undefined): Maybe<T> {
  return value;
}

// 使用时
function doThing(user: Maybe<User>, thing: Maybe<Thing>): Result {
  const safeUser = user ?? defaultUser;
  // ...
}

核心还是依托统一的可空类型来避免签名冗余。

总结来说，最务实的方案是统一项目内的可空类型定义+通过规范/工具强制执行，既能简化方法签名，也能避免同类类型混乱的问题。

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