fp-ts中HKT与Kind、Kind2等类型的匹配机制解析

先看fp-ts中lift函数的重载实现：

export function lift<F extends URIS2>(F: Functor2<F>): <A, B>(f: (a: A) => B) => <E>(fa: Kind2<F, E, A>) => Kind2<F, E, B>
export function lift<F extends URIS>(F: Functor1<F>): <A, B>(f: (a: A) => B) => (fa: Kind<F, A>) => Kind<F, B>
export function lift<F>(F: Functor<F>): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B>
export function lift<F>(F: Functor<F>): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B> {
  return (f) => (fa) => F.map(fa, f)
}

这个函数可以完美适配Identity、Option、Either等Functor实例：

const double = (n: number): number => n * 2

const doubleIdentity = lift(I.Functor)(double)
const doubleOption = lift(O.Functor)(double)
const doubleEither = lift(E.Functor)(double)

核心疑问 #

1. 为什么最后一个重载export function lift<F>(F: Functor<F>): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B>是最通用的fallback场景？结合HKT、Kind、Kind2的定义，看起来各类型并不匹配。
2. fp-ts早期文章中曾把HKT的所有属性直接添加到Option这类类型中，但实际实现并非如此，如何解释lift函数中Kind、Kind2与HKT的类型匹配原理？

解答 #

1. 最后一个重载作为fallback的原因

TypeScript的重载匹配是从上到下优先匹配更具体的定义：

• 前两个重载分别针对双参数高阶类型（URIS2，比如Either<E, A>）和单参数高阶类型（URIS，比如Option<A>），约束更严格，会优先匹配对应类型的Functor实例。
• 最后一个重载没有URIS/URIS2的约束，只要求F符合Functor<F>的结构，是最宽泛的定义。当前面的具体重载都不匹配时（比如自定义的未用URIS标记的高阶类型），它会作为兜底，确保函数能处理所有符合Functor契约的类型。

从类型兼容性来看，Kind<F, A>和Kind2<F, E, A>都是HKT<F, A>的子类型——TypeScript是结构类型系统，只要一个类型包含了另一个类型的所有必要属性，就会被认为兼容。HKT<F, A>只要求带有_URI和_A两个类型标记属性，而Kind/Kind2在映射到实际类型（比如Option<A>）的同时，也会带上这些标记属性，因此完全可以赋值给HKT<F, A>类型的参数。

2. Kind、Kind2与HKT的类型匹配原理

由于TypeScript没有原生支持高阶类型（HKT），fp-ts通过类型别名+URIS标记+映射类型的方式模拟实现：

• HKT：是最基础的高阶类型模板，仅包含_URI（高阶类型标记）和_A（参数类型）两个类型属性，用来表示“带有类型参数A的高阶类型F”。
• URIS/URIS2：是字符串字面量类型（比如"Option"、"Either"），用来给不同的高阶类型做唯一标记，方便类型映射。
• Kind/Kind2：是HKT的具体实例化类型别名。比如Kind<F extends URIS, A>会通过URItoKind映射类型，把URIS标记转换成实际的类型（比如URItoKind<"Option", number>就是Option<number>），同时保留_URI和_A标记。换句话说，Kind<"Option", number>本质上就是Option<number>，只是在类型层面带上了HKT的标记属性，让TypeScript能识别它是一个单参数的高阶类型。
• Functor1/Functor2：分别是单参数、双参数高阶类型的Functor约束，它们的实例（比如O.Functor）会实现map方法，并且关联对应的URIS标记。

早期文章中直接给Option添加HKT属性的方式比较直观，但会污染实际的类型结构；现在fp-ts改用类型别名的方式，完全在类型层面完成HKT的模拟，不需要修改实际的类/接口，既保证了类型安全，又避免了对运行时结构的影响。

当调用lift(O.Functor)(double)时，TypeScript会匹配到第二个重载（因为O.Functor属于Functor1<"Option">），返回的函数参数类型是Kind<"Option", number>（即Option<number>），而在函数内部，F.map接收的fa实际上就是普通的Option<number>实例，类型标记仅在编译期生效，不影响运行时逻辑。

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