Java 中不存在公共的 ObjectMethods 类，它只是 JDK 内部 Record 实现中一个 package-private 工具类，不对外暴露、不可导入或反射访问，其存在性和签名无保障；开发者应使用 java.util.Objects 作为稳定替代方案。
Java 中没有 ObjectMethods 类，也不是 JDK 内部 Record 的“辅助工具”——这是对 JDK 源码中一个私有工具类的常见误读。
为什么搜 ObjectMethods 会看到 Record 相关代码？
在 JDK 14+ 的 java.lang.Record 实现中，确实存在一个名为 ObjectMethods 的 package-private 工具类（位于 jdk.internal.reflect 或 java.lang.runtime 包下，具体路径随版本变动），但它不对外暴露，也不属于公共 API。它被 Record 编译器生成的 equals/hashCode/toString 方法底层调用，用于统一处理字段比较、散列计算和字符串拼接逻辑。
常见错误现象：在 IDE 中跳转 Record 的 toString() 实现，或反编译 class 文件时看到对 ObjectMethods.toString 的调用，误以为这是个可直接使用的工具类。
- 它只在 JVM 内部被
Record的合成方法调用，无法 import，不能 new，也不能反射访问 - JDK 不保证其存在性或签名稳定性——JDK 17 后部分逻辑已内联或重构，某些版本甚至已移除该类名
- 它的行为与开发者手写的
Objects.equals()或Objects.hash()不完全等价（例如对null字段的处理策略、字段遍历顺序）
Objects 才是你该用的公共替代方案
如果你需要类似 ObjectMethods 提供的字段级操作能力（比如安全比较、散列、字符串格式化），应使用 java.util.Objects —— 这是唯一稳定、公开、文档化的标准工具类。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
使用场景：手写 equals/hashCode/toString；调试时快速比对对象字段；构建不可变容器的辅助逻辑。
-
Objects.equals(a, b)：安全处理null，避免 NPE，但不会递归比较嵌套对象字段 -
Objects.hash(fields...)：按参数顺序计算散列值，与 Record 自动生成的hashCode行为接近（但不保证完全一致） -
Objects.toString(obj, "null")：提供默认空值表示，但不生成结构化字段输出（Record 的toString是"R[a=1, b=null]"形式，Objects.toString只返回"R@123"或自定义字符串）
示例：
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person person = (Person) o;
return Objects.equals(name, person.name) &&
Objects.equals(age, person.age);
}
Record 的实际行为依赖编译器，不是运行时类库
Record 的 equals/hashCode/toString 行为由 javac 在编译期生成字节码决定，而非运行时动态调用某个固定类。即使 ObjectMethods 存在，也只是实现细节之一；不同 JDK 版本可能用不同方式生成这些方法（如内联逻辑、调用其他私有方法、甚至直接展开字节码）。
- 不要试图通过反射或字节码操作去“复刻” Record 的行为——它不跨版本兼容
- 不要在生产代码中依赖
jdk.internal.*包下的任何类，--illegal-access=deny下会直接失败 - 如果需要高度可控的结构化行为（比如忽略某些字段、自定义格式），老老实实写普通类 + Lombok
@Data或手动实现，别绕到内部类上
真正容易被忽略的是：ObjectMethods 这个名字本身只是 JDK 开发者随手起的内部类名，不是设计契约。它既不面向用户，也不承载语义承诺——你看到它，说明你已经踩进源码细节的深水区了，而那里通常不是解决问题的正确位置。
