深入探讨typescript类型推断的微妙之处：四种函数返回值类型定义的等价性及联合类型下的类型安全
本文深入分析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;
这四种类型定义都旨在从函数类型中提取返回值类型。虽然参数类型(never, never[], any[], any) 不同，但它们在类型推断中对返回值类型R的推断结果并无影响。extends关键字关注的是函数类型的结构，而非参数的具体类型。只要函数类型匹配，infer R都能正确推断出返回值类型。因此，这四种定义实际上是等价的。
接下来，我们分析一段代码，它展示了联合类型和条件类型结合时可能出现的类型错误：
type Props<T extends Major | ResCategoryLabel> = { labels: T[]; setSelect: (index: number, label: T extends Major ? Major : ResCategoryLabel) => void; xxx: any; // 省略其他属性 }; const changeSelect = ( index: number, label: Major | ResCategoryLabel, e: React.MouseEvent<HTMLAnchorElement> | React.TouchEvent<HTMLAnchorElement> ) => { setSelect(index, label); activeTabToCenter(e.currentTarget as HTMLElement); };
Props类型定义中的setSelect函数参数label的类型推断存在问题。条件类型T extends Major ? Major : ResCategoryLabel试图根据T的类型来确定label的类型。然而，由于T是Major | ResCategoryLabel的联合类型，当T的实际类型未知时，编译器无法确定T是Major还是ResCategoryLabel，导致label的类型推断失败。 问题并非条件类型本身，而是它在联合类型上下文中的应用。
解决方法是直接使用Major | ResCategoryLabel作为label的类型：
type Props<T extends Major | ResCategoryLabel> = { labels: T[]; setSelect: (index: number, label: Major | ResCategoryLabel) => void; xxx: any; // 省略其他属性 };
这样，setSelect函数的参数类型明确，避免了类型错误，提高了代码的可读性和可维护性。 这体现了在处理联合类型时，有时需要放弃条件类型带来的精细化类型控制，以换取更清晰和安全的类型定义。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
