java中equals方法的核心是匹配业务语义而非语法正确：不同场景下“相等”定义不同，需先明确使用场景、比对主体及目的，再选择字段；须尽量遵守官方合约，但浮点数比较等可合理例外。
Java 中 equals 方法的实现，核心不是“写对语法”，而是“对齐业务语义”。同一个类在不同场景下，相等的定义可能完全不同——比如用户对象，在登录校验时可能只看账号名；在数据同步时却要求所有字段（含最后更新时间）完全一致。因此，符合业务的 equals，本质是把业务里“什么时候算同一个东西”翻译成代码逻辑。
明确业务场景再决定比较字段
不要一上来就重写 equals，先问清楚：这个对象在哪用？谁在比？比完干什么？
- 订单对象用于缓存去重 → 可能只比订单号（唯一业务键），忽略状态、创建时间等可变字段
- 实体类用于 MyBatis 查询结果比对 → 通常需包含主键 + 乐观锁版本号，避免脏读误判
- DTO 用于前端传参校验 → 若前端不传 ID，就得靠业务字段组合（如手机号+身份证号）判断是否重复提交
遵守 equals 合约，但允许有业务例外
官方合约（自反、对称、传递、一致性、非空性）必须尽量满足，但某些业务场景下可合理放宽：
- 浮点数字段比较不用
==，改用Math.abs(a - b) ，这是精度容忍，不是破坏合约 - 时间字段若业务只要“同一天”，就用
LocalDate.from(time1).equals(LocalDate.from(time2))，而非毫秒级全等 - 集合字段（如 List
）若业务只关心“包含哪些标签”，可用 containsAll + size判断，不强求顺序一致
注意 null 和类型安全，避免运行时异常
业务对象常含可选字段（如 address 可为 null），直接调用 field.equals(other.field) 容易 NPE。推荐写法：
- 用
Objects.equals(a, b)—— 自动处理两边 null、一边 null、都不 null 的情况 - 类型检查用
other instanceof YourClass，别用getClass() == other.getClass()，否则子类实例无法与父类实例相等（除非业务明确禁止多态比较） - 如果业务允许“空地址”和“未设置地址”视为相同，那就统一按 null 处理；如果“空字符串”和 null 算不同，则要显式区分
配套重写 hashCode，且逻辑与 equals 严格对应
只要 equals 里用了哪些字段，hashCode 就只能用**完全相同**的字段参与计算，一个都不能多、不能少、不能换规则：
- 若 equals 比了 id + name，hashCode 就得用
Objects.hash(id, name) - 若 equals 对 price 做了四舍五入比较（如保留两位小数），hashCode 也得先 round 再参与计算，否则 HashMap 查不到
- 数据库生成的 ID 在对象刚 new 出来时为 null，但业务上认为“未保存的两个新对象不算相等”，那 hashCode 就不该包含 id 字段，或给未保存对象返回固定值（如 0）
不复杂但容易忽略：每次修改业务字段含义，都要回头检查 equals 和 hashCode 是否还成立。它们不是一次写完就封存的工具方法，而是随业务演进持续维护的契约代码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
