Objects.equals 比 == 或 equals() 安全在哪
它内部先判 null，再调用对象的 equals() 方法。如果两个参数都是 null，返回 true；只有一个为 null，返回 false；都非空才真正比较。这直接绕开了手动判空的繁琐和遗漏风险。
常见错误现象：写 a.equals(b) 时，a 是 null 就抛 NullPointerException；写 a == b || a.equals(b) 又容易漏掉 b 为 null 的情况。
- 使用场景：任意两个可能为
null的引用类型比较，比如String、Integer、自定义 POJO 字段 - 不要用于基本类型（如
int、boolean），它们不能为null，用==更直接 - 性能影响极小，JVM 对这个方法做了内联优化，别担心“多一次方法调用”
Objects.equals 和 Objects.deepEquals 的区别
Objects.equals 是浅比较，只调用对象自身的 equals()；Objects.deepEquals 会递归进入数组或嵌套结构，适合含 int[]、List 等容器的场景。
容易踩的坑：误用 Objects.equals 比较两个 int[]，结果永远是 false（因为数组没重写 equals()），实际需要的是 Arrays.equals(a, b) 或 Objects.deepEquals(a, b)。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
Objects.equals(new int[]{1}, new int[]{1})→false -
Objects.deepEquals(new int[]{1}, new int[]{1})→true -
Objects.deepEquals对非数组对象仍退化为Objects.equals，所以不是“一定更安全”，而是“用途不同”
自定义类里 equals() 写得不规范，Objects.equals 也救不了你
Objects.equals 最终还是会走到你写的 equals() 方法里。如果这个方法没处理 null、没检查类型、没比较所有关键字段，那外部用 Objects.equals 也只是把空指针延后了一层，该错还是错。
典型错误：在 equals() 里直接强转 other 为本类，没先用 instanceof 判类型，或没处理 other == null。
- 务必保证
equals()遵循对称性、传递性、一致性，且对null返回false - IDE 自动生成的
equals()（如 IntelliJ 的Alt+Insert）通常靠谱，但要检查是否漏了新字段 - 如果类不可变，考虑用
record，它的equals()是语言级保障的
替代方案：Optional.orElse(null) 不等于 Objects.equals 的语义
有人想“既然怕 null，那就统一用 Optional 包一层”，但这是错位设计。Optional 表达的是“值可能存在”，而 Objects.equals 解决的是“两个值要不要算相等”。混用反而让逻辑变重、可读性下降。
比如 Optional.ofNullable(a).orElse("") 和 Optional.ofNullable(b).orElse("") 再比较，就改变了原始语义——原本 null 和 "" 是不同的，现在被强行等价了。
- 不要为了用
Optional而用，它不解决比较问题，也不替代Objects.equals - 如果业务上
null和空字符串确实等价，那应在领域层做归一化，而不是在每次比较时补丁式处理 - 最轻量、最无副作用的方式，就是老老实实调
Objects.equals(a, b)
真正容易被忽略的是：很多人只记得用 Objects.equals 去比较字段，却忘了在 hashCode() 里同步处理——只要重写了 equals()，就必须重写 hashCode()，否则放进 HashSet 或作 HashMap key 时行为就不可预期。
