为何内联Scala函数可修复collect引发的运行时类型转换异常？

问题背景 #

你提供的Scala代码在调用非内联的泛型minBy函数时，会触发ClassCastException（Herbivore无法转换为Food），但将该函数改为内联后就能正常运行并输出Some(Food(1))。这是完全符合预期的行为，核心原因在于Scala的泛型类型擦除机制和内联函数的特性差异。

非内联函数出错的原因 #

Scala的泛型基于JVM实现，而JVM在运行时会擦除泛型类型信息。对于你的非内版minBy函数：

def minBy[T <: GameObject](f: T => Double): Option[T] =
    xs.collect{case v: T => v}.minByOption(f)

• 编译后，泛型参数T的具体类型会被擦除为它的上界GameObject，所以运行时case v: T实际上等同于case v: GameObject。
• 这意味着xs.collect会把所有GameObject实例（包括Herbivore）都保留下来，生成一个Vector[GameObject]。
• 后续调用minByOption(f)时，传入的函数food => food.x要求参数是Food，但集合里存在Herbivore实例，JVM会尝试把Herbivore强制转换为Food，最终抛出ClassCastException。

内联函数修复问题的原理 #

当你把minBy标记为内联函数后：

inline def minBy[T <: GameObject](f: T => Double): Option[T] =
    xs.collect{case v: T => v}.minByOption(f)

• 内联函数会在调用点被编译器直接展开，此时编译器明确知道调用时传入的T是Food。
• 展开后的代码中，case v: T会被直接替换为case v: Food，xs.collect只会过滤出Food实例，生成Vector[Food]。
• 后续调用minByOption(f)时，集合里只有Food对象，函数food => food.x能正常执行，不会出现类型转换错误。

结论 #

这种差异是完全预期的行为，本质是内联函数让泛型类型在编译期就完成了具体化，避开了JVM泛型类型擦除带来的运行时类型安全问题。

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