重写toString和equals必须遵守契约：toString应简洁安全、避免异常和敏感信息；equals与hashCode必须同时重写且逻辑一致，字段比较用Objects.equals，哈希计算用Objects.hash。
重写 toString 和 equals 是 Java 开发中高频但易出错的操作，核心在于保持语义一致性和遵守契约规范。
toString 方法：清晰表达对象状态
默认的 Object.toString() 只返回类名+哈希码，对调试和日志毫无帮助。重写时应体现对象的关键业务属性，避免包含动态计算值或敏感信息。
- 用
Objects.toStringHelper()（Guava）或String.format()构建可读字符串，例如：return String.format("User{id=%d, name='%s', email='%s'}", id, name, email); - 若字段可能为
null，优先用Objects.toString(field)防止空指针，而非直接拼接 - 不建议在
toString中调用其他对象的toString形成无限递归（如双向关联）
equals 方法：必须同时重写 hashCode
equals 的重写不是“要不要”的问题，而是“怎么写才不出错”。只要重写了 equals，就必须重写 hashCode，否则违反散列表（HashMap、HashSet）契约。
- 先用
==判断引用相等，再用instanceof检查类型，最后逐字段比较（推荐用Objects.equals(a, b)处理null） - 只比较影响逻辑相等性的字段，忽略计算字段、时间戳、数据库 ID（除非业务要求）
-
hashCode必须基于与equals中相同的字段计算，推荐用Objects.hash(f1, f2, f3)
常见陷阱与规避方式
很多 bug 来自看似合理实则违规的写法。比如在 equals 中修改对象状态，或在 toString 中触发 I/O。
立即学习“Java免费学习笔记（深入）”；
- 不要在
equals或hashCode中调用可能抛异常的方法（如 getter 内含校验逻辑） - 继承场景下，若子类新增字段参与相等判断，需谨慎处理：要么让父类
equals声明为final，要么使用“对称性”方案（如 Apache Commons Lang 的EqualsBuilder.reflectionEquals仅作参考，生产环境慎用） - Lombok 的
@EqualsAndHashCode和@ToString能大幅减少模板代码，但需明确指定include或exclude字段，避免默认包含全部字段引发意外行为
IDE 与工具辅助生成
现代 IDE（IntelliJ / Eclipse）可一键生成基础版本，但生成结果需人工审查。
- IntelliJ 生成时勾选 “Include superclass
equals()/hashCode()” 若存在继承关系；取消勾选 “Use getters” 除非所有字段都通过 getter 访问且无副作用 - 检查生成的
hashCode是否遗漏字段，或误将boolean字段用(field ? 1 : 0)而非Boolean.hashCode(field) - 单元测试必须覆盖：相同对象、不同对象、
null参数、对称性、传递性、一致性（尤其涉及可变字段时）
