getClass()要求运行时类完全相同，instanceof允许子类实例；前者用于值对象等需严格类型一致的场景，后者适用于接口实现等强调行为契约的场景。
在 Java 中，getClass() 和 instanceof 在类型判断上本质不同：前者严格要求**运行时类完全相同**，后者只要求**是某类或其任意子类的实例**。这个差异直接影响对象相等性（equals）中“同类”与“子类”的判定逻辑。
getClass() 保证“同一种类”，排除继承关系干扰
obj.getClass() == this.getClass() 是最严格的类型一致性检查。它返回的是对象**实际创建时的 Class 对象**，子类实例调用会返回子类的 Class，永远不等于父类的 Class。
- 适合用于要求“必须是同一个类的实例才可能相等”的场景，比如值对象（Value Object）、不可变数据类
- 能天然防止子类绕过父类
equals的语义约束（例如子类添加了新字段但没重写equals，用instanceof可能误判为相等） - 典型用法：
public boolean equals(Object obj) {<br> if (obj == null || getClass() != obj.getClass()) return false;<br> MyData other = (MyData) obj;<br> return value == other.value;<br>}
instanceof 允许“向上兼容”，接受子类实例
obj instanceof MyType 在 obj 为 MyType 或其任意子类实例时都返回 true。它基于**继承关系图谱**，而非精确类匹配。
- 适合强调“行为契约一致”的场景，比如接口实现类、策略模式中的具体策略
- 若父类
equals已定义好核心逻辑，且子类不改变相等语义（仅扩展行为），可用instanceof简化判断 - 风险：若子类重写了关键字段但未重写
equals，instanceof可能让两个逻辑上不等的对象被判定为相等
选择依据：看你的“相等”定义依赖结构还是契约
这不是语法技巧问题，而是语义设计选择：
- 如果两个对象要“相等”，必须具有**完全相同的类结构和字段集**（如
Point和它的子类ColoredPoint不应视为相等），用getClass() - 如果只关心它们是否满足某个**公共接口或抽象行为定义**（如所有
Shape子类按面积比较），且你控制所有子类的equals实现，instanceof更灵活 - 注意：二者不能混用。同一类层次中，要么全用
getClass()（推荐对称性），要么确保所有子类正确覆盖equals并统一用instanceof
一个常见陷阱：instanceof + 向下转型不安全
仅用 obj instanceof MyParent 判断后直接强转为 MyParent 没问题，但若后续想访问子类特有字段，就会失败——因为 instanceof 不告诉你具体是哪个子类。
- 错误示范：
if (obj instanceof MyParent) {<br> MyParent p = (MyParent) obj;<br> return p.id == this.id && p.name.equals(this.name); // 忽略子类新增字段<br>} - 正确做法：要么用
getClass()锁定类型，要么在instanceof后用if-else分支处理各已知子类，或使用 Visitor 模式
