继承中toString和equals需确保语义互换性与状态真实性：toString须包含父类关键属性并推荐super.toString()复用；equals必须用getClass()而非instanceof以保障对称性与传递性；hashCode须与equals字段严格一致。
在继承结构中正确处理 toString 和 equals，关键不是“能不能用”，而是“要不要让子类和父类在语义上可互换比较”以及“字符串输出是否真实反映当前对象状态”。多数业务实体类应坚持类型严格、字段完整、行为一致的原则。
toString 要体现当前类的全部有效状态
子类重写 toString 时，不能只拼接自己新增字段，必须包含从父类继承的关键属性。否则打印出来的信息不完整，调试时容易误判。
- 推荐用
super.toString()复用父类逻辑，再追加子类字段，例如：return super.toString() + ", department=" + department; - 避免手写硬编码格式（如
"name:" + name + ", age:" + age），IDE 生成或Objects.toStringHelper（Guava）/ToStringBuilder（Apache Commons）更安全 - 如果父类
toString返回空或占位符（如"Parent@1234"），说明它没被正确重写，子类不能依赖它——此时应完整写出所有字段，包括父类的
equals 必须用 getClass() 做类型检查
用 instanceof 看似方便，但在继承链中极易破坏对称性和传递性。比如 Employee.equals(Person) 返回 true，但反过来却返回 false，集合操作就会出错。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 每个具体类的
equals都应先判断obj.getClass() == this.getClass()，确保只和同类型实例比较 - 子类实现中，校验通过后调用
super.equals(obj)，复用父类字段比较逻辑；注意传的是原始obj，不是转型后的引用 - 若父类本身用了
instanceof且无法修改，子类不能靠调用super.equals()修复问题，必须整体重写并统一用getClass()
配套处理 hashCode 和字段一致性
equals 和 hashCode 是一对契约：相等的对象必须有相同哈希码；参与 equals 比较的字段，一个都不能少地参与 hashCode 计算。
- 用
Objects.hash(name, age, gender, department)生成哈希码，自动处理 null，简洁可靠 - 子类新增用于
equals判断的字段，必须同步加入hashCode；反之，如果某个字段没参与equals，就不该出现在hashCode中 - 不要在
hashCode或equals中调用可能改变状态的方法（如 getter 触发懒加载或计算），避免副作用
实际开发中的取舍建议
不是所有继承场景都需要重写这两个方法。要根据类的设计意图来判断：
- 抽象基类（如
Shape）通常不直接实例化，可定义模板方法，但把equals和toString留给具体子类实现 - DTO、Record 类建议用 IDE 自动生成，再人工核对字段是否齐全；避免漏掉父类字段或新增字段
- 如果子类只是扩展行为而非改变身份定义（如
AdminUser extends User），且业务上允许AdminUser和User实例逻辑相等，那需在抽象父类中明确定义比较策略，并由所有子类严格遵循——但这属于例外，非常规做法
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
