Rust的trait与Java的interface是否一致？为何命名为trait而非interface

首先要先澄清一个认知偏差：Rust的trait和Java的interface并不是同一类概念，选择trait这个名字有明确的技术层面考量，完全不是命名偏好。

核心原因有几个：

• 两者的能力边界完全不同
  Java的interface是典型的纯面向对象设计产物，本质是类的行为契约，只能被类实现，最多在高版本Java中支持默认方法、静态方法，能力边界非常窄。而Rust的trait是来自编程领域早已成型的*特征（Trait）*设计概念，能力覆盖范围远大于传统接口：
  • 支持默认实现，且默认实现可以调用同trait内的其他未实现方法
  • 支持给已存在的第三方类型实现自定义trait（在孤儿规则约束下），比如你可以给标准库的String类型扩展实现你自己写的trait，这在Java中是完全做不到的
  • 支持关联类型、泛型约束、运算符重载，还可以作为动态分发的抽象类型使用，这些能力都超出了传统interface的设计范畴
• 避免术语误导
  如果Rust沿用interface这个命名，会让大量有Java/C#编程背景的开发者先入为主地将它和传统OOP接口划等号，忽略掉trait独有的特性，反而会提升学习成本，也不符合Rust多范式的设计定位——毕竟Rust本身就不是纯面向对象语言，没必要硬套纯OOP语言的术语体系。
• 术语本身的精确性
  计算机领域的trait概念本来就被定义为「可复用、可组合的行为集合，不绑定类型的继承体系」，和Rust的设计完全匹配，反过来interface的语义本来就绑定了「类实现的契约」这个OOP专属的属性，用来描述Rust的这个特性本来就不精确。

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