为何Object类要在类型层次根节点提供equals与hashCode方法？

很多以类似Object的类作为类型层次根节点的面向对象编程语言（比如Java、C#），都会在根类型中默认提供相等性（equals/Equals）和哈希码（hashCode/GetHashCode）方法。虽然值语义对象（如Integer、Guid）需要重写这些方法来实现值相等，而行为语义对象（如服务、控制器）通常不需要，但为什么这些方法会被放在根类型里，而非通过接口按需实现？以下是几个核心原因：

1. 保证所有对象的基础相等判断能力 #

所有对象都存在最基础的相等判断需求：判断两个对象是否为同一个实例。根类型提供的默认实现（引用相等）正好满足这种通用需求，让任意对象都能直接进行实例比较，无需额外的类型检查或接口实现。

如果改为接口模式（比如Equatable<T>），未实现接口的对象将无法直接进行相等判断，会破坏语言操作的一致性——比如你无法简单写出一个能比较任意两个对象是否为同一实例的通用逻辑，必须增加额外的分支处理，提升了代码复杂度。

2. 历史兼容性与泛型普及前的设计约束 #

Java和C#这类语言在早期版本中没有泛型（Java 5、C# 2.0才引入泛型），当时的集合类（如Java的Hashtable、C#的ArrayList）都是以Object作为存储类型。把equals和hashCode放在根类型里，能确保所有对象都可以直接被集合类处理，无需额外的接口约束。

泛型普及后，为了兼容大量旧代码和现有生态，这种设计也无法轻易修改——如果改成接口模式，旧的集合类和依赖根类型相等性的代码都会失效，重构成本极高。

3. 统一相等性逻辑，避免冗余判断 #

如果用接口来定义相等性，通用代码需要同时处理两种情况：实现了接口的对象用自定义相等逻辑，未实现的用引用相等。这会让通用逻辑变得繁琐。而根类型的默认实现把这种逻辑统一了：所有对象都有equals方法，默认是引用相等，需要自定义值相等的对象只需重写方法即可，无需额外的类型判断。

4. 语言生态与开发者习惯的延续 #

经过数十年的使用，“所有对象都具备equals和hashCode”已经成为开发者的默认认知，大量框架、库、工具（如序列化、反射组件）都基于这个设计构建。比如序列化工具会用equals判断对象状态是否一致，缓存框架会用hashCode生成缓存键。如果改成接口模式，整个生态都需要重构，成本不可承受。

有没有不采用这种设计的编程语言？ #

当然有，部分现代语言采用了“接口/协议按需实现”的模式：

• Swift：Swift的类默认仅支持引用相等（===），要实现值相等必须主动遵守Equatable协议；结构体和枚举则默认自动实现Equatable。哈希码相关的逻辑则通过Hashable协议定义，需主动实现才能用于Set或Dictionary。
• Rust：Rust通过trait（类似接口）处理相等性和哈希逻辑：PartialEq/Eq trait定义相等判断，Hash trait定义哈希码生成。类型必须主动实现这些trait，才能被用于HashMap、HashSet等集合中，不存在根类型提供的默认实现。

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