重写equals方法必须遵循自反性、对称性、传递性、一致性四大原则及非空性要求：自反性要求this==obj时返回true；对称性须用getClass()而非instanceof；传递性禁用可变字段；一致性要求参与比较的字段尽量final；非空性要求equals(null)恒返回false。
重写 equals 方法不能只靠“写对字段比较”，必须让逻辑经得起运行时各种调用场景的检验。四大原则——自反性、对称性、传递性、一致性——不是理论条文，而是防止集合行为异常、调试无头绪、线上偶发失配的实际防线。
自反性：自己跟自己比必须为 true
这是最基础的安全底线。如果 user.equals(user) 返回 false，任何基于 equals 的通用逻辑（比如 Collection.contains()、List.remove()）都会出错，甚至触发不可预期的空指针或循环中断。
实现要点：
- 开头第一行就加
if (this == obj) return true; - 不要跳过这步去直接做类型检查或字段比较——哪怕对象是 final 类或字段全为 null，也必须先保自反
- 避免在重写中误用代理、装饰器或延迟初始化导致
this在比较中途状态不一致
对称性：a.equals(b) 和 b.equals(a) 必须同真同假
违反对称性最常见于子类与父类混用、或引入非同类对象参与比较的场景。例如：父类 Person 允许和 String 比姓名，而 String 不支持反向调用 equals(Person)，就会崩。
立即学习“Java免费学习笔记（深入）”；
安全写法：
- 严格使用
getClass() == obj.getClass()判断类型，不用instanceof（后者对子类返回 true，破坏对称） - 若确实需要跨类型比较（如
BigDecimal与int），必须确保对方类也显式兼容你，且双方约定一致 - 遇到
null或非法类型，统一返回false，不抛异常
传递性：三者之间不能出现“循环相等”
典型陷阱是引入可变字段（如时间戳、版本号）或近似比较（如浮点容差、字符串忽略大小写但未全局统一规则）。例如：
A 和 B 姓名相同、年龄差1岁 → 视为相等；B 和 C 年龄差1岁 → 也相等；但 A 和 C 差2岁 → 不相等。这就打破了传递性。
保障方式：
- 只用不可变、业务语义上“决定身份”的字段参与比较（如 ID、code、name + version 等稳定标识）
- 避免用
new Date()、System.nanoTime()、随机数、缓存状态等动态值 - 若涉及格式化/归一化（如邮箱小写、手机号去空格），确保所有实例在构造或 setter 中已统一处理，而非每次 equals 里临时转换
一致性：只要对象不变，结果就不能变
这个原则直指“可变性风险”。如果一个对象在放入 HashSet 后修改了参与 equals 比较的字段，它可能再也找不回来——因为哈希桶位置没更新，而 equals 又因字段变了不再匹配。
关键实践：
- 参与 equals 的字段尽量声明为
final，从源头杜绝意外变更 - 若必须可变（如 DTO 接收外部数据），确保业务层在对象进入集合前已完成赋值，之后不再修改关键字段
- 单元测试中要覆盖“修改字段前后调用多次 equals”的用例，验证返回值是否恒定
非空性虽常被列为第五条，但它其实是自反性和对称性的前置守门员：任何 equals(null) 都必须返回 false，否则 Objects.equals(a, b) 这类工具方法会失效，集合操作也可能抛 NPE。所以标准模板里第二步永远是 if (obj == null) return false;。
