为何在Remeda的Reverse泛型类型中使用ReturnType？

先对比你提到的两段实现代码：

带ReturnType的实现 #

type Reverse<
  T extends ReadonlyArray<unknown>,
  R extends ReadonlyArray<unknown> = [],
> = ReturnType<
  T extends IsNoTuple<T>
    ? () => [...T, ...R]
    : T extends readonly [infer F, ...infer L]
      ? () => Reverse<L, [F, ...R]>
      : () => R
>;

直接返回的预期实现 #

type Reverse<
  T extends ReadonlyArray<unknown>,
  R extends ReadonlyArray<unknown> = []
> =
  T extends IsNoTuple<T>
    ? [...T, ...R]
    : T extends readonly [infer F, ...infer L]
      ? Reverse<L, [F, ...R]>
      : R

核心原因是利用TypeScript的条件类型延迟求值特性，规避递归类型的过早解析问题：

• TypeScript对直接返回递归类型的条件分支，会尝试即时展开递归逻辑，这在处理复杂元组或泛型参数时，容易触发编译器的递归深度限制，或者导致类型推断不符合预期（比如无法准确区分固定长度元组和可变长度数组）。
• 把递归逻辑包装在() => ...函数类型里，再用ReturnType提取返回值，相当于告诉编译器：等需要具体解析这个类型的时候，再处理内部的递归。这种延迟解析的方式，能让递归逻辑更稳定地工作——尤其是在元组反转这种需要逐元素递归推导的场景中，可避免编译器提前终止递归或推断错误。

举个实际场景：如果用直接返回的版本，传入较长的固定长度元组时，部分TS版本可能因递归深度问题报错，而带ReturnType的版本能正常完成反转推导；对于泛型参数的场景（比如函数参数是泛型数组），延迟解析也能让类型推断更精准。

这种技巧是TypeScript社区为绕过递归条件类型限制总结的通用方案，本质是用函数类型作为“容器”推迟递归的展开时机。

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