typescript 类型推断的迷惑：四种等效的 returntype 类型定义及条件类型与联合类型匹配的挑战
本文深入探讨 TypeScript 中一些令人费解的类型推断行为。我们将分析四种看似不同的类型定义，解释它们为何最终产生相同的结果，并解决一个与条件类型和联合类型匹配相关的难题。
首先，让我们观察这四种 getReturnType 类型定义：
type getReturnType1<T> = T extends (...args: never) => infer R ? R : never; type getReturnType2<T> = T extends (...args: never[]) => infer R ? R : never; type getReturnType3<T> = T extends (...args: any[]) => infer R ? R : never; type getReturnType4<T> = T extends (...args: any) => infer R ? R : never;
表面上，这四种定义在函数参数 args 的类型上有所区别：never，never[]，any[] 和 any。然而，在 TypeScript 的类型推断机制下，它们的结果完全一致。这是因为在条件类型 T extends (...args: TArgs) => infer R 中，...args 主要用于匹配函数参数的数量和类型，而不会影响返回值类型 R 的推断。无论 args 的类型为何，只要 T 是函数类型，infer R 都会准确推断出函数的返回值类型。因此，这四种定义在实际应用中是等效的。
接下来，我们分析第二个问题，关于条件类型和联合类型的匹配：
type Props<T extends Major | ResCategoryLabel> = {
labels: T[];
setSelect: (index: number, label: T) => void;
xxx: any; // 保留原有代码
};
const changeSelect = (
index: number,
label: Major | ResCategoryLabel,
e: React.MouseEvent<HTMLAnchorElement> | React.TouchEvent<HTMLAnchorElement>
) => {
// setSelect(index, label); // 原代码此处报错
const props = {labels: [label], setSelect: (i, l) => {}} as Props<typeof label>; // 添加类型断言
props.setSelect(index, label); // 使用类型断言后的 Props
activeTabToCenter(e.currentTarget as HTMLElement);
};
这段代码中，setSelect 函数的参数 label 的类型定义为 T，依赖于泛型 T。其初衷是根据 T 的类型来确定 label 的类型。然而，在 changeSelect 函数中，label 的类型是 Major | ResCategoryLabel，这与 setSelect 函数参数类型在某些情况下不匹配，导致 TypeScript 报错。
问题在于，T 在 Props 类型定义中是一个泛型类型，其具体类型只有在 Props 被使用时才能确定。changeSelect 函数调用 setSelect 时，T 的类型是未知的，TypeScript 无法在编译时确定 label 的具体类型。
解决方法是：在 changeSelect 函数中更精确地指定 label 的类型，或者修改 setSelect 的类型定义。 简单的 // @ts-ignore 并非最佳实践，因为它掩盖了潜在问题，不利于代码的可维护性和可读性。 上面的例子通过类型断言的方式解决了这个问题，明确指定了Props泛型类型T。 这需要根据实际情况选择合适的解决方法，确保类型安全。
