F#内联向下转型的编译器优化及集合类型拆分疑问

我在研读F#核心库源码时，发现一种常见的基类+密封子类+内联向下转型的模式，示例代码如下：

简化模式示例：

type Class1() = ...
type Class2() =
   inherit Class1()

let inline asClass1 t = t :?> Class1

F#核心库中Set的具体实现：

[<NoEquality; NoComparison>]
[<AllowNullLiteral>]
type internal SetTree<'T>(k: 'T, h: int) =
    member _.Height = h
    member _.Key = k
    new(k: 'T) = SetTree(k, 1)

[<NoEquality; NoComparison>]
[<Sealed>]
[<AllowNullLiteral>]
type internal SetTreeNode<'T>(v: 'T, left: SetTree<'T>, right: SetTree<'T>, h: int) =
    inherit SetTree<'T>(v, h)
    member _.Left = left
    member _.Right = right

let inline private asNode (value: SetTree<'T>) : SetTreeNode<'T> =
    value :?> SetTreeNode<'T>

针对这个模式的疑问，以下是具体解析：

一、编译器对该向下转型的优化情况 #

• 关键在于SetTreeNode<'T>是密封类（Sealed）：密封类无法被继承，JIT处理value :?> SetTreeNode<'T>时，只需要检查对象的实际类型是否就是SetTreeNode<'T>，不需要遍历整个继承层级，这本身就比非密封类的向下转型快很多。
• 加上inline关键字后，编译器会把函数体直接嵌入调用位置。如果调用asNode的上下文明确知道传入的SetTree<'T>实例一定是SetTreeNode<'T>（比如Set的平衡树操作中，只有非叶子节点才会进入需要调用asNode的分支），编译器可以直接消除类型检查的开销，把对象当成SetTreeNode<'T>来处理。
• 就算没法完全消除检查，密封类的转型开销也极小，几乎可以忽略。

二、该模式的核心作用：可读性、复用性与内存优化 #

• 复用代码：基类SetTree<'T>封装了叶子节点和非叶子节点共有的属性（Key、Height），避免重复编写相同逻辑；子类SetTreeNode<'T>只负责非叶子节点特有的左右子节点逻辑。
• 提升可读性：asNode内联函数替代了重复的 :?> SetTreeNode<'T>转型代码，让逻辑更清晰，减少不必要的视觉噪音。
• 内存优化：叶子节点可以直接用更轻量的SetTree<'T>实例（不需要存储左右子节点字段），非叶子节点才用SetTreeNode<'T>，在大规模集合场景下能节省不少内存。

三、拆分Map和Set底层类型的原因 #

• 语义与类型安全：Map是键值对集合，Set是单一元素集合，拆分类型能明确区分两者的语义，避免跨类型误用，类型系统会提前拦截这类错误。
• 针对性优化：两者核心逻辑有差异（比如Map要处理键值对的存储与查找，Set只需要处理元素），分开实现可以针对各自场景做特定优化，避免冗余逻辑。
• 减少内存开销：Map的节点需要额外存储Value字段，Set不需要，拆分类型可以避免Set节点携带不必要的字段，进一步优化内存占用。

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