为何Scala与sbt可编译不含otherProperty的Test类代码？

首先先还原你可能的代码结构（根据描述推测）：

class Test(val name: String)

object Test {
  // 带implicit的转换函数
  implicit def toTestMapped(obj: Any): Test = {
    obj.asInstanceOf[Test].otherProperty // 访问Test不存在的属性
  }
}

object Main extends App {
  val test = new Test("demo")
  println(test.otherProperty) // 触发问题的调用
}

这是一个典型的Scala隐式转换机制带来的“编译时放过，运行时崩溃”的场景，咱们一步步拆解：

1. 为什么带implicit的toTestMapped能让代码编译通过？ #

当Scala编译器遇到一个对象调用不存在的成员（比如test.otherProperty，而Test类根本没有otherProperty）时，它会自动启动隐式转换查找逻辑：试图找到一个隐式转换函数，把当前对象转换成某个拥有该成员的类型。

你的toTestMapped函数刚好踩中了编译器的推断盲区：

• 它标记了implicit，属于编译器可自动调用的隐式转换范畴
• 参数类型是Any（Test实例自然可以匹配这个参数），返回类型是Test

编译器此时会陷入一个自我循环的推断逻辑：它认为可以通过这个隐式转换把Test实例转换成Test类型（虽然这看起来完全没必要，但编译器只做类型匹配检查，不会去质疑转换的合理性），然后错误地假设转换后的Test对象拥有otherProperty——因为隐式转换的存在，它跳过了对Test类实际成员的直接检查，转而依赖转换后的类型来验证成员存在性。就这样，编译器判定这段代码是合法的，允许通过编译。

2. 为什么运行时会触发StackOverflowError？ #

当代码运行到obj.asInstanceOf[Test].otherProperty这一行时，又会触发完全相同的逻辑：这个Test实例依然没有otherProperty，JVM会再次调用隐式转换toTestMapped，而转换函数里又会访问otherProperty，如此无限递归下去，直到JVM的调用栈耗尽，抛出StackOverflowError。

3. 为什么移除implicit或修改属性名后编译失败？ #

• 移除implicit关键字：此时toTestMapped不再是隐式转换函数，编译器找不到任何能把Test转换成拥有otherProperty类型的隐式转换，于是直接报错：Test类没有otherProperty这个成员。
• 修改otherProperty的名称：比如改成Test类实际存在的name，此时编译器直接访问Test实例的name成员，完全不需要触发隐式转换逻辑，自然也不会进入之前的错误推断流程，直接发现原来的调用不合法。

总结 #

这个问题的本质是Scala隐式转换机制的“过度推断”：当隐式转换的参数和返回类型形成循环（这里是Any => Test，而Test是Any的子类），编译器会错误地认为转换后的类型满足成员访问需求，从而放过编译错误，但运行时会陷入无限递归。

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