== 比较对象引用是否相同（内存地址），equals 比较逻辑内容是否相等；String 等类重写了 equals 以比较字符序列，而 == 在字符串常量池与 new 创建对象时结果不可靠。
Java 中 equals 和 == 判等结果不一致，到底在比什么
根本区别不在“要不要重写”，而在比较目标不同：== 比的是内存地址（引用是否指向同一对象），equals 默认行为也是比地址，但设计初衷是留给子类覆盖、用来比逻辑相等——比如两个 String 内容一样就该算相等，哪怕不是同一个实例。
常见错误现象：用 == 判断两个新创建的 String 是否“内容相同”，结果是 false；或对自定义类没重写 equals 就直接调用，误以为它会自动比较字段值。
-
==是运算符，编译期绑定，无法被重载，永远只看引用是否相同 -
equals是Object的实例方法，可被重写，实际行为取决于运行时对象类型 - 基本类型（如
int、boolean）只能用==，没有equals方法（包装类才有）
String 为什么用 equals 而不用 ==
因为字符串常量池和对象创建方式导致引用不可靠。字面量 "abc" 会进池，但 new String("abc") 一定新建堆对象，两者 == 必为 false，但内容完全一致。
示例：
String a = "hello";
String b = "hello";
String c = new String("hello");
System.out.println(a == b); // true（同池中引用）
System.out.println(a == c); // false（堆中新对象）
System.out.println(a.equals(c)); // true（重写了，比字符序列）
- 不要依赖字符串常量池做判等依据，它受编译器优化、
intern()调用等影响 - 所有字符串内容比较必须用
equals，包括与null比较前要先判空，否则可能抛NullPointerException - 如果确定是字面量且无运行时拼接，
==可能快一点，但语义错位，不值得冒险
自定义类忘记重写 equals 的后果
直接继承 Object.equals，等价于 ==，两个字段完全相同的对象仍被判为不等——集合操作（如 HashSet.contains、HashMap.get）全失效。
典型场景：用 Person 对象作 Map 的 key，或放进 ArrayList 后用 contains 查找，结果找不到。
- 重写
equals必须同时重写hashCode，否则违反契约，哈希容器行为未定义 - 判断逻辑要覆盖所有业务上认为“相等”的字段，忽略无关状态（如临时缓存、创建时间）
- 注意
null安全：用Objects.equals(field1, field2)替代手动判空 + 比较
性能与兼容性：什么时候 == 反而更合理
当明确只需要确认“是不是同一个对象”时，== 更快、更安全。比如单例校验、事件监听器去重、缓存 key 的快速预检。
示例：
if (listener == this) return; // 避免重复注册自己
-
==是零成本比较，equals至少有一次虚方法调用 + 字段读取开销 - 某些框架内部（如 Hibernate 代理对象）重写
equals会触发懒加载，用==可规避副作用 - 跨 JVM 或序列化后对象，引用关系已丢失，
==失效，此时只能依赖equals逻辑
最易被忽略的点：很多人以为“重写了 equals 就万事大吉”，但没意识到 == 在某些边界场景下才是语义正确且高效的选择——关键不是哪个“更好”，而是你此刻想表达的，究竟是身份一致，还是内容一致。
