为什么TypeScript跨文件导出的联合类型常量会被降级为string类型

问题原因 #

1. 你在constants.ts中给导出的常量a、b手动标注了联合类型AOrB，这导致两个常量的类型被定义为联合的'a' | 'b'，而非具体的字面量类型'a'和'b'。
2. 代码放在同一文件时，TypeScript可以做全量上下文推导，跟踪到两个常量的实际赋值就是对应的字面量，因此计算属性的键可以正确识别为'a'和'b'。
3. 拆分到多文件后，哪怕isolatedModules设置为false，TypeScript也不会做跨模块的深度取值推导，只会读取常量的标注类型AOrB。当联合类型作为计算属性的键时，类型会被拓宽为string，导致最终生成的对象类型被推导为{[x: string]: string}，和要求的ObjWithAOrB类型不匹配。

解决方案 #

方案1：用satisfies约束常量类型（推荐，TS 4.9+支持） #

不直接给常量标注联合类型，让TypeScript自动推导常量的字面量类型，再用satisfies保证常量符合AOrB的约束，既保留字面量类型，又做类型校验：

// constants.ts
import type { AOrB } from './types';

export const a = 'a' as const satisfies AOrB;
export const b = 'b' as const satisfies AOrB;

方案2：手动断言为字面量类型（兼容低版本TS） #

如果使用的TS版本低于4.9不支持satisfies，可以直接用as const固定字面量类型，额外增加类型校验避免写错常量值：

// constants.ts
import type { AOrB } from './types';

export const a = 'a' as const;
export const b = 'b' as const;

// 编译时类型校验，确保常量符合AOrB定义，写错会报错
type _ValidateA = typeof a extends AOrB ? true : never;
type _ValidateB = typeof b extends AOrB ? true : never;

方案3：对象层面做类型断言（临时兼容方案） #

如果不想修改常量定义，可以直接给最终的obj对象做类型断言，绕过类型检查：

// obj.ts
import { a, b } from './constants';
import { ObjWithAOrB } from './types';

export const obj = {
  [a]: 'foo',
  [b]: 'bar',
} as ObjWithAOrB;

这个方案属于兜底方案，没有从根源解决常量类型被拓宽的问题，不推荐长期使用。

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