应优先使用 getclass()，因其能确保对称性和传递性；instanceof 仅在类为 final 或明确约定子类字段不参与比较时才安全。
重写 equals 时，用 getClass() 还是 instanceof，核心在于是否允许子类实例与父类实例相等——这直接关系到 对称性（symmetry） 和 传递性（transitivity） 是否被破坏。正确选择取决于你的设计意图，但多数场景下，getClass() 更安全。
为什么 instanceof 可能破坏对称性
假设 Person 类用 instanceof Person 判断类型，子类 Student extends Person 也重写了 equals 且同样用 instanceof Person：
-
person.equals(student)→ true（student 是 Person 实例） -
student.equals(person)→ true（person 也是 Person 实例）→ 表面看没问题
但如果 Student 加了新字段（如 studentId），并在自己的 equals 中参与比较，而 Person.equals 完全忽略它，就可能出现：
-
person.equals(student1)→ true（只比 name/age） -
person.equals(student2)→ true -
student1.equals(student2)→ false（因 studentId 不同）
这就违反了传递性：true ∧ true ⇏ true。更隐蔽的是，若 Student.equals 用 instanceof Person，但 Person.equals 用 instanceof Student（错误写法），直接导致 person.equals(student) 为 true 而 student.equals(person) 为 false —— 对称性当场崩塌。
getClass() 如何保障对称性与传递性
getClass() 返回运行时精确类对象，确保只有**同类实例**才可能相等：
-
person.equals(student)→ false（person.getClass() != student.getClass()） -
student.equals(person)→ false -
student1.equals(student2)→ 按完整字段比较，逻辑可控
这样天然满足对称性、传递性，也避免父类和子类因字段差异引发的不一致。适用于“父子类语义不同”的场景，比如 Point 和 ColorPoint：颜色信息对相等性有实质影响，二者不应视为等价。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
什么时候可以安全用 instanceof
仅当满足以下全部条件时，instanceof 才可接受：
- 该类是 final 的（无法被继承）
- 或你明确设计为“子类扩展不影响相等逻辑”，且所有子类都严格遵循同一套字段比较规则（极难保证）
- 并已通过文档声明：相等性只基于父类定义的字段，子类新增字段不参与比较（用户需自觉遵守）
例如：public final class UserId { ... }，此时 instanceof UserId 安全且简洁。
标准写法建议（推荐 getClass）
除非你有强理由支持多态相等，否则默认用 getClass()：
@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (obj == null || getClass() != obj.getClass()) return false;
Person person = (Person) obj;
return age == person.age && Objects.equals(name, person.name);
}
注意：不要写成 obj.getClass() == this.getClass()（可能因类加载器不同失败），始终用 getClass() != obj.getClass()。
本质上这不是语法技巧问题，而是建模选择：把相等性绑定到具体类型，还是开放给继承体系。多数业务实体应选前者——稳定、可预测、符合直觉。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
