总的来说，Kotlin 中的每个设计决策都让人感觉它本身就很棒，并且提供了从 Java 的良好过渡。作为一名 Java 开发人员，您可以开始在其中进行编码，将 Kotlin 视为一种更简洁的 Java，更少样板，然后顺利地进入更高级的方面，如函数式编程。
然而，我想知道的一件事是为什么它的设计者决定使其==行为相同equals，然后引入===参照相等检查。我可以想象尝试让其他 Java 开发人员参与进来，让他们看到您的 Kotlin 代码并想“哦，不，到处都有引用检查，它应该是一个相等的调用！”
在这里摆脱 Java 约定的思考过程是什么？为了清楚起见，我完全理解Kotlin 中==orequals和之间的区别===，我只是想知道为什么。
主要原因可能是检查对象相等性比检查对象身份更频繁，所以它至少应该一样容易。
我还没有看到关于这方面的明确声明。但是在Kotlin In Action一书中有一个指针，由 Kotlin 团队的成员撰写。第 4.3.1 节，介绍==操作符，首先描述了 Java 的比较并说：
在 Java 中，众所周知的做法是总是调用
equals，而众所周知的问题是忘记这样做。
在 Java 中，检查对象身份很容易：
if (firstObj == secondObj)
但是检查对象相等性更长，而且不太清楚：
if (firstObj.equals(secondObj))
— 或者更确切地说，如果您不想冒 NullPointerException 的风险：
if ((firstObj == null) ? (secondObj == null) : firstObj.equals(secondObj))
你可以看到打字和正确打字是多么痛苦。（特别是当其中一个对象是具有副作用的表达式时……）
所以很容易忘记区别，或者不介意，==转而使用。（这可能会导致微妙、难以发现和断断续续地咬人的虫子。）
然而，Kotlin 使最常见的操作变得更容易：它的==运算符使用 来检查对象是否相等equals()，并且还负责检查空值。这解决了 Java 的“忘记这样做的问题”。
（虽然与 Java 代码的互操作性显然是一个主要目标，但 JetBrains 并没有限制自己试图看起来像 Java；Kotlin 尽可能地借鉴了 Java，但不害怕将事情变得更好。你可以在声明的使用val和var尾随类型，范围和开放性的不同默认值，处理差异的不同方式等）
Kotlin 的动机之一是解决 Java 中的许多问题。（事实上，JetBrains 对语言的比较首先列出了“Kotlin 中解决的一些 Java 问题”。）所以这似乎是改变背后的主要原因。
除了 gidds 的出色回答之外，除了 Java 之外，还有其他语言对 Kotlin 产生了强烈的影响。特别是 Scala 和 C#。Dmitry Jemerov的一句话（链接是 InfoWorld，我不太喜欢，但这是我找到的最好的来源）：
我们查看了所有现有的 JVM 语言，但没有一个能满足我们的需求。Scala 具有正确的特性，但其最明显的缺陷是编译速度非常慢。
显然==，这是他们认为 Scala 正确的功能之一，因为它的工作原理完全相同（直到引用相等的名称，它eq在 Scala 中）。
您可以在“Scala 编程”一书中找到对 Scala 设计的解释，该书的作者之一是 Martin Odersky：
如 11.2 节所述，Scala 和 Java 对相等的定义是不同的。Java 有两种相等比较：== 运算符，它是值类型的自然相等和引用类型的对象标识，以及 equals 方法，它是（用户定义的）引用类型的规范相等。这个约定是有问题的，因为更自然的符号 == 并不总是对应于自然的平等概念。使用 Java 编程时，初学者的一个常见陷阱是在对象本应与 equals 进行比较时将它们与 == 进行比较。例如，使用 "x == y" 比较两个字符串 x 和 y 在 Java 中很可能会产生错误，即使 x 和 y 具有完全相同的字符以相同的顺序。
Scala 也有一个表示对象身份的等式方法，但它用得不多。如果 x 和 y 引用同一个对象，那么这种写成“x eq y”的相等是正确的。== 相等在 Scala 中保留用于每种类型的“自然”相等。对于值类型，== 是值比较，就像在 Java 中一样。对于引用类型，== 与 Scala 中的 equals 相同。您可以通过重写 equals 方法为新类型重新定义 == 的行为，该方法始终继承自类 Any...
另一方面，C# 允许==与 分开重载Equals，他们最终得到一个语言设计者说
长答案是，整个事情都很奇怪，而且都没有按照理想的方式工作。