TypeScript类型推断的迷惑之处：四种等效的ReturnType类型定义及条件类型与联合类型匹配的难题？

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 都会准确推断出函数的返回值类型。因此，这四种定义在实际应用中是等效的。

接下来，我们分析第二个问题，关于条件类型和联合类型的匹配：

Qoder

阿里巴巴推出的AI编程工具

270

查看详情

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。 这需要根据实际情况选择合适的解决方法，确保类型安全。

以上就是TypeScript类型推断的迷惑之处：四种等效的ReturnType类型定义及条件类型与联合类型匹配的难题？的详细内容，更多请关注php中文网其它相关文章！