Scala混合含相同抽象类型成员的Trait时的类型兼容疑问

这是个非常有意思的问题，刚好触及了Scala类型系统处理特质叠加时的核心规则细节。我会一步步拆解你的疑问：

疑问1：为什么混合具体类型的上下界特质会报错？ #

你的实验里，当你在object FamilyMember中混合LowerBound[GrandGrandchild]和UpperBound[Parent]并显式指定type M = Child时，编译器能够验证Child同时满足> GrandGrandchild和< Parent的约束，所以顺利通过。但当你把这两个特质混合成一个新的特质FamilyTreeConstraint时，编译器却抛出了类型不兼容的错误。

核心原因在于Scala处理特质中同名抽象类型成员的叠加逻辑：

• 当你混合两个都定义了type M的特质时，编译器并不会自动将两个约束合并为type M >: GrandGrandchild <: Parent这种复合上下界约束。
• 它会将两个特质中的type M视为对同一抽象成员的两个独立定义，一个要求M是GrandGrandchild的超类型，另一个要求M是Parent的子类型。由于这两个约束是“反向”的，编译器默认判定它们是冲突的，而不会主动去验证这两个约束的交集是否非空（哪怕我们知道GrandGrandchild是Parent的子类型，交集确实存在）。

简单来说，编译器在处理特质层面的抽象类型叠加时，没有做“约束兼容性验证”的额外逻辑——它只看两个约束是否是可以直接合并的同向约束（比如两个下界取更严格的那个，两个上界取更宽松的那个），而上下界混合的情况会被直接判定为不兼容。

疑问2：是否类型细化先于类型约束检查执行？ #

答案是否定的。实际上，类型约束检查在特质定义阶段就已经执行了，远早于后续的类型细化步骤：

• 当你定义FamilyTreeConstraint时，编译器会立即检查所有叠加特质中的同名类型成员的约束是否兼容，此时没有具体的M类型可以验证，所以直接抛出冲突错误。
• 而在object FamilyMember中，你显式提供了M的具体类型Child，编译器此时才会检查这个具体类型是否满足两个特质的约束，这一步是在对象定义阶段的约束验证，而非“先细化再检查”。

如果想要实现类似“复合上下界约束”的特质，更合适的写法是直接定义一个带有复合约束的抽象类型成员，就像你提到的：

trait UpperLower[T,U]{ type M >: T <: U }

然后继承时指定具体的T和U：

trait FamilyTreeConstraint extends UpperLower[GrandGrandchild, Parent]

这种写法下，编译器会明确识别到M是一个同时带有上下界的抽象类型，并且会验证T <: U（这里GrandGrandchild <: Parent成立），所以不会报错，后续也可以正常细化M为Child或Grandchild。

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