TypeScript类型推断迷惑：四种定义同结果，条件与联合类型难题？

本文深入探讨TypeScript类型推断的微妙之处，特别是四种看似不同的函数返回值类型定义(`getReturnType1`-`getReturnType4`)如何得出相同结果，以及条件类型与联合类型匹配的难题。文章分析了`extends`关键字在类型推断中的行为，解释了即使参数类型为`never`, `never[]`, `any[]`, `any`，类型推断仍能正确获取返回值类型的原因。此外，文章还剖析了一个`setSelect`函数中条件类型与联合类型(`Major | ResCategoryLabel`)不匹配的案例，并指出这是TypeScript类型系统在处理联合类型和条件类型时的限制，而非代码逻辑错误，最后提出了可能的解决方案，例如重构类型定义或使用类型断言。 关键词：TypeScript, 类型推断, 条件类型, 联合类型, 类型匹配, 类型安全

TypeScript类型推断的微妙之处：四种类型定义的相同结果及条件类型与联合类型的匹配难题

本文探讨TypeScript中几种看似不同的类型定义却产生相同结果的原因，并解释一个条件类型与联合类型匹配的问题。

首先，我们分析四种getReturnType类型的定义：

type getReturnType1 = T extends (...args: never) => infer R ? R : never;
type getReturnType2 = T extends (...args: never[]) => infer R ? R : never;
type getReturnType3 = T extends (...args: any[]) => infer R ? R : never;
type getReturnType4 = T extends (...args: any) => infer R ? R : never;

这四种类型定义都旨在从函数类型中推断其返回值类型。尽管参数类型(...args: never)、(...args: never[])、(...args: any[])和(...args: any)看起来不同，但在类型推断中却表现一致。这是因为extends关键字主要关注函数的参数个数和返回值类型，而不会严格检查参数类型的细节。never代表不可能存在的类型，any代表任何类型，never[]代表空数组；这些差异在返回值类型推断过程中被忽略。因此，都能正确推断出函数的返回值类型R。

接下来，我们分析一个条件类型与联合类型不匹配的问题：

type Props = {
  labels: T[];
  setSelect: (index: number, label: T extends Major ? Major : ResCategoryLabel) => void;
  xxx;
};

const changeSelect = (
  index: number,
  label: Major | ResCategoryLabel,
  e: React.MouseEvent | React.TouchEvent
) => {
  setSelect(index, label);
  activeTabToCenter(e.currentTarget as HTMLElement);
};

setSelect函数的第二个参数label的类型定义为T extends Major ? Major : ResCategoryLabel。问题在于，当T为Major | ResCategoryLabel时，TypeScript无法确定label的类型。条件类型试图根据T是否为Major来选择类型，但T可能是Major也可能是ResCategoryLabel，导致类型推断无法给出确定的类型，从而出现类型不匹配错误。这不是代码逻辑错误，而是TypeScript类型系统在处理联合类型和条件类型时的限制。 解决方法可能需要重构Props类型或setSelect函数的类型定义，例如使用类型断言或更精细的类型定义来明确label的类型。

终于介绍完啦！小伙伴们，这篇关于《TypeScript类型推断迷惑：四种定义同结果，条件与联合类型难题？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！