TypeScript中从产品常量生成条件排列类型并验证函数全量有效分支处理的实现方案问询

问题背景 #

我们有一个定义好的产品常量PRODUCTS，其中每个产品标记了是否允许试用。现在需要实现类型安全的函数分支处理：

1. 从PRODUCTS自动生成所有有效（产品code + 试用状态）的类型组合
2. 函数中可以分别检查code和isTrial参数（而非拼接成字符串），且TypeScript能自动做类型收窄
3. 编译时强制验证所有有效状态分支都被处理，避免新增/修改产品时遗漏分支

原方案用字符串拼接生成状态类型，依赖手动排除无效组合，不够灵活且维护成本高。我们需要更贴合PRODUCTS结构的类型生成方式，以及更自然的分支验证逻辑。

解决方案：自动生成关联类型 + 编译期穷尽分支检查 #

步骤1：从PRODUCTS生成关联类型

首先，我们基于PRODUCTS常量，自动生成产品code与允许的试用状态的关联类型，让TypeScript能根据code推断isTrial的合法取值：

const PRODUCTS = {
  BASIC: { code: 'basic', trialPermitted: false },
  PRO: { code: 'pro', trialPermitted: true },
  // 后续新增产品直接加在这里即可
} as const;

// 提取所有产品code的联合类型
type ProductCode = (typeof PRODUCTS)[keyof typeof PRODUCTS]['code'];

// 核心：根据产品code，返回该产品允许的isTrial取值
type AllowedTrialForCode<C extends ProductCode> = 
  // 当产品不允许试用时，isTrial只能是false
  C extends (typeof PRODUCTS.BASIC)['code'] ? false :
  // 当产品允许试用时，isTrial可以是true/false
  C extends (typeof PRODUCTS.PRO)['code'] ? boolean :
  // 兜底的never类型，确保新增产品时类型会报错提示
  never;

步骤2：实现类型安全的函数 + 穷尽分支验证

接下来，我们定义函数参数类型，让TypeScript自动关联code和isTrial的合法组合，同时用穷尽匹配守卫确保所有有效分支都被处理：

// 穷尽匹配守卫：如果走到这里，说明有未处理的分支，编译时会报错
const exhaustiveMatchingGuard = (_: never): never => {
  throw new Error('未处理的产品状态分支');
};

function describeProduct<C extends ProductCode>(
  code: C,
  isTrial: AllowedTrialForCode<C>
): string {
  // 分支1：处理不允许试用的产品（如BASIC）
  if (code === PRODUCTS.BASIC.code) {
    // TypeScript会自动推断这里isTrial只能是false，无需额外判断
    return 'Basic';
  }

  // 分支2：处理允许试用的产品（如PRO）
  if (code === PRODUCTS.PRO.code) {
    if (isTrial) {
      return 'Pro Trial';
    }
    return 'Pro';
  }

  // 兜底分支：如果新增了产品但没加处理逻辑，TypeScript会报错
  // 因为此时code的类型是never（新增产品后AllowedTrialForCode会更新，code不再是never）
  return exhaustiveMatchingGuard(code);
}

方案优势 #

1. 完全基于PRODUCTS自动维护类型：新增/修改产品或trialPermitted字段时，类型会自动更新，无需手动维护状态组合
2. 自然的分支逻辑：无需拼接字符串，直接分别检查code和isTrial，代码可读性更高
3. 编译期强制分支全覆盖：新增产品但未添加处理分支时，TypeScript会在兜底分支报错，提示遗漏的逻辑
4. 类型收窄自动生效：TypeScript会根据当前code自动推断isTrial的合法取值，避免无效状态的传入

常见疑问解答 #

Q: 为什么不直接把描述文本存在PRODUCTS的字段里？

A: 实际场景中有多个类似describeProduct的函数，每个函数返回值类型/逻辑都不同（比如有的返回价格，有的返回权限列表），只有「有效状态组合」是共通的，把所有逻辑存在产品字段里会导致耦合过重。

Q: 为什么不直接复制产品定义（同一code对应不同isTrial状态）？

A: 产品数量多、字段多的情况下，复制会导致大量冗余代码，维护成本极高。我们的方案完全复用现有PRODUCTS结构，避免冗余。

内容来源于stack exchange