Scala Shell中重复声明同名变量的编译机制与优先级问题

这个问题问得很接地气——毕竟在常规Scala项目代码里，重复声明同名变量会直接触发编译错误，但Scala Shell（REPL）却偏偏开了这个“绿灯”，下面就拆解背后的逻辑：

1. Scala Shell的本质：REPL的独立作用域机制 #

Scala Shell是一个Read-Eval-Print Loop（交互式解释器），它和普通Scala编译器的核心区别是：每一行输入都会被包裹在一个独立的局部作用域中执行，而非把所有代码放在同一个全局作用域里。

举个类比，就像你在代码里写了一串嵌套代码块：

{
  val a = 1 // 第一个作用域的a
}
{
  val a = 2 // 第二个独立作用域的a，和第一个毫无关系
}
{
  var a = 3 // 第三个作用域的var a，同样是全新变量
}

REPL的每一次输入就对应一个独立的代码块，每次声明的同名变量都是全新的实体，只是会**遮蔽（shadow）**之前作用域里的同名变量——你当前只能访问最后一次声明的那个，但之前的变量并没有被销毁，只是在当前上下文不可见了。

2. 不存在“优先级”，只是作用域遮蔽 #

你提到的“先声明val a=1再声明var a=2，哪一个优先级更高”其实是个伪命题：这两个变量属于不同的作用域，不存在优先级竞争。

比如你执行以下操作：

scala> val a = 1
a: Int = 1
scala> var a = 2
a: Int = 2
scala> a = 3
a: Int = 3

这里最后一行能成功赋值，是因为当前上下文的a是第二个声明的var变量，和第一个val a没有任何关联——第一个val a还存在于它自己的作用域里，但你在当前环境已经访问不到它了。

如果最后声明的是lazy val a=1，那它的行为和常规Scala里的lazy val完全一致：只有当你第一次访问a时，才会执行初始化逻辑。

3. 为什么要允许这种行为？ #

这完全是为了提升交互式体验：REPL的核心用途是快速测试代码片段、验证逻辑，允许重复声明同名变量，能让开发者不用重启Shell、不用重构代码，就能快速修改变量定义、测试不同的实现。如果像普通编译器那样严格禁止重复声明，交互式测试的效率会大打折扣。

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