Kotlin 与 Java 10 中 var 关键字的差异对比

1. 概述

本文将对比 Kotlin 与 Java 10 中 var 关键字的使用方式与语义差异。虽然两者在语法层面看起来很相似，但在实际使用中存在一些关键区别。

如果你对 Java 10 中的 var 感兴趣，可以参考我们之前的文章《Java 10 局部变量类型推断》；而 Kotlin 中的 var 用法详见《Kotlin 中的 const、var 与 val》。

2. 类型声明方式不同

2.1 Kotlin

在 Kotlin 中，使用 var 声明变量时，可以不写类型，编译器会根据初始值自动推断类型：

var myVariable = 1

当然，也可以显式指定类型：

var myVariable: Int = 1

⚠️ 如果你只声明变量而不立即初始化，就必须指定类型：

var myVariable: Int
myVariable = 1

2.2 Java

Java 10 中的 var 只能用于局部变量，而且必须在声明时初始化，否则会编译失败：

var myVariable = 1;

以下写法是错误的：

var myVariable; // ❌ 编译错误
myVariable = 1;

编译器会报错：

Cannot infer type: 'var' on variable without initializer

3. 关键字 vs 标识符

在 Kotlin 中，var 是一个关键字（keyword），因此不能作为变量名、方法名或类名使用。

而在 Java 10 中，var 是一个受限标识符（restricted identifier），这意味着：

✅ 你可以将它用作变量名、方法名或参数名：

public void var() {
    // do something
}

public void method(int var) {
    // do something
}

public void method() {
    int var = 1;
    // do something
}

❌ 但你不能用它来定义类名：

public static class var { } // ❌ 编译错误

错误信息如下：

Error:(1, 1) java: 'var' not allowed here
  as of release 10, 'var' is a restricted type name and cannot be used for type declarations

这种设计是为了保持与旧版本 Java 的兼容性。

4. 可变性差异

在 Kotlin 中，var 表示可变变量，它始终是可变的。

而在 Java 中，var 只是类型推断语法糖，变量本身可以是可变或不可变，取决于是否加上 final：

var mutableInt = 1;        // ✅ 可变
final var immutableInt = 1; // ✅ 不可变

Kotlin 中没有 final 关键字，而是使用 val 来声明不可变变量：

val immutableInt = 1 // ✅ 不可变

5. 作用域差异

5.1 Kotlin

Kotlin 中的 var 可用于：

全局变量
类成员变量
局部变量

示例：

var myGlobalVar = 3

class MyClass {
    var myVar = 3

    fun myFunction(): Int {
        var myVariable = 3
        return myVariable
    }
}

5.2 Java

Java 中的 var 只能用于局部变量，不能用于类成员或全局变量：

public class MyClass {
    // ❌ 不允许这样写
    // private var myVar = 1;

    public int myFunction() {
        var myVariable = 3; // ✅
        return myVariable;
    }
}

6. 总结

对比维度	Kotlin 中的 `var`	Java 10 中的 `var`
类型声明	可省略，也可显式指定	必须初始化，不能显式指定
是否为关键字	是（不能作为变量名）	否（受限标识符，可用作变量名）
可变性	始终可变	可变或不可变（配合 `final`）
作用域	全局、类成员、局部	仅限局部变量
主要用途	声明可变变量	类型推断

✅ 总结一句话：Kotlin 中的 var 强调变量的可变性，而 Java 中的 var 强调类型推断机制。

虽然两者语法相似，但背后语义和设计哲学差异较大，使用时要注意区分，避免踩坑。

Persistence

REST

Security