虽然很多人已经回答了Val和var之间的区别。 但是需要注意的一点是val并不完全像final关键字。

我们可以用递归改变val的值，但我们永远不能改变final的值。Final比Val更恒定。

def factorial(num: Int): Int = {
 if(num == 0) 1
 else factorial(num - 1) * num
}

方法参数默认为val，并且在每次调用时都会更改值。

在javascript方面，它与

val -> const 是 -> 是

Val表示不可变，var表示可变。

完整的讨论。

Val是最终值，即不能设置。在java中考虑final。

Val表示不可变，var表示可变

您可以将val视为Java编程语言的final key world或c++语言的const key world。

正如许多人所说，赋值给val的对象不能被替换，而赋值给var的对象可以。但是，该对象可以修改其内部状态。例如:

class A(n: Int) {
  var value = n
}

class B(n: Int) {
  val value = new A(n)
}

object Test {
  def main(args: Array[String]) {
    val x = new B(5)
    x = new B(6) // Doesn't work, because I can't replace the object created on the line above with this new one.
    x.value = new A(6) // Doesn't work, because I can't replace the object assigned to B.value for a new one.
    x.value.value = 6 // Works, because A.value can receive a new object.
  }
}

所以，即使我们不能改变赋值给x的对象，我们可以改变这个对象的状态。然而，在它的根源上，有一个var。

不变性有很多好处。首先，如果一个对象没有改变内部状态，您就不必担心代码的其他部分是否正在改变它。例如:

x = new B(0)
f(x)
if (x.value.value == 0)
  println("f didn't do anything to x")
else
  println("f did something to x")

这在多线程系统中尤为重要。在多线程系统中，可能会发生以下情况:

x = new B(1)
f(x)
if (x.value.value == 1) {
  print(x.value.value) // Can be different than 1!
}

如果您只使用val，并且只使用不可变数据结构(即避免数组)，则scala.collection中的所有内容。可变的，等等)，你可以放心，这不会发生。也就是说，除非有一些代码，甚至是一个框架，执行反射技巧——不幸的是，反射会改变“不可变”的值。

这是一个原因，但还有另一个原因。当您使用var时，您可能会出于多种目的重用相同的var。这有一些问题:

对于阅读代码的人来说，要知道在代码的某个部分中变量的值将更加困难。 您可能会忘记在某些代码路径中重新初始化变量，并最终在代码中向下传递错误的值。

简单地说，使用val更安全，代码可读性更强。

那么，我们可以走另一个方向。如果val更好，为什么还要var呢?好吧，有些语言确实采取了这条路线，但在某些情况下，可变性可以大大提高性能。

例如，以一个不可变队列为例。当您对其中的事物进行排队或出队列时，您将获得一个新的Queue对象。那么，你将如何处理其中的所有项目呢?

我会用一个例子来解释。假设你有一个数字队列，你想把它们组合成一个数字。例如，如果我有一个有2,1,3的队列，按这个顺序，我想要得到数字213。让我们先用一个可变变量来解决它。队列:

def toNum(q: scala.collection.mutable.Queue[Int]) = {
  var num = 0
  while (!q.isEmpty) {
    num *= 10
    num += q.dequeue
  }
  num
}

这段代码快速且易于理解。它的主要缺点是传递的队列是由toNum修改的，因此您必须事先复制它。这就是不变性让你摆脱的对象管理。

现在，让我们把它转换成一个不可变的。队列:

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  def recurse(qr: scala.collection.immutable.Queue[Int], num: Int): Int = {
    if (qr.isEmpty)
      num
    else {
      val (digit, newQ) = qr.dequeue
      recurse(newQ, num * 10 + digit)
    }
  }
  recurse(q, 0)
}

因为我不能像前面的例子那样重用某个变量来跟踪num，所以我需要使用递归。在这种情况下，它是一个尾递归，它有很好的性能。但情况并非总是如此:有时就是没有好的(可读的，简单的)尾部递归解决方案。

但是请注意，我可以重写该代码以使用一个不可变变量。队列和一个变量在同一时间!例如:

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  var qr = q
  var num = 0
  while (!qr.isEmpty) {
    val (digit, newQ) = qr.dequeue
    num *= 10
    num += digit
    qr = newQ
  }
  num
}

这段代码仍然是高效的，不需要递归，也不需要担心在调用toNum之前是否必须复制队列。当然，我避免了为其他目的重用变量，这个函数之外的任何代码都看不到它们，所以我不需要担心它们的值会在每行之间发生变化——除非我显式地这样做。

Scala选择让程序员这样做，如果程序员认为这是最好的解决方案。其他语言选择了使这样的代码变得困难。Scala(以及任何具有广泛可变性的语言)所付出的代价是，编译器在优化代码方面没有足够的余地。Java对此的答案是基于运行时概要文件优化代码。我们可以继续讨论每一方的利与弊。

就我个人而言，我认为Scala达到了恰当的平衡。到目前为止，它并不完美。我认为Clojure和Haskell都有Scala没有采用的非常有趣的概念，但Scala也有自己的优势。我们会看到未来会发生什么。