Objects.equals能防NPE，因其内部先判空：二者同为null返回true，仅一者为null返回false，均非null才调用a.equals(b)，彻底避免空指针异常。
Objects.equals 为什么能防 NPE
Objects.equals 内部做了 null 判空，先检查两个参数是否都为 null（此时返回 true），再检查其中一个为 null（此时返回 false），最后才调用第一个非 null 对象的 equals 方法。这避免了手动写 a != null && a.equals(b) 的重复逻辑和漏判风险。
什么时候必须用 Objects.equals 而不是 == 或直接调用 equals
以下场景直接调用 obj1.equals(obj2) 极易触发 NullPointerException：
-
obj1为null（比如从 Map.get()、Optional.orElse(null)、数据库查询结果中拿到的可能为空引用） - 不确定两个对象是否都已初始化（如 DTO 字段未赋值、JSON 反序列化时字段缺失）
- 比较的是泛型类型变量（编译期无法推断是否可空，静态分析工具也常告警）
而 == 只比引用，对字符串、包装类、自定义对象几乎总是错的；Objects.equals 是语义相等的安全兜底。
Objects.equals 和 Objects.deepEquals 的关键区别
Objects.equals 是浅比较：对数组类型（如 int[]、String[]）会直接用 == 比较引用，结果往往不符合预期；Objects.deepEquals 才会对数组做元素级递归比较。
常见误用：
- 用
Objects.equals(new String[]{"a"}, new String[]{"a"})→ 返回false（因为两个数组引用不同） - 正确做法是改用
Objects.deepEquals(...)，或对数组单独用Arrays.equals(...) -
Objects.deepEquals性能略低，且对循环引用会抛StackOverflowError，生产环境慎用于嵌套过深或不可信的数据结构
实际编码中容易忽略的细节
即使用了 Objects.equals，仍有几个坑：
- 它不解决
equals方法本身写得不对的问题——如果类没重写equals，仍会走Object.equals（即引用比较） - 对浮点数包装类（
Double、Float），Objects.equals(Double.NaN, Double.NaN)返回true，但new Double(Double.NaN).equals(new Double(Double.NaN))也返回true，这点其实一致；真正要注意的是0.0和-0.0在Double.equals中被视为不等，Objects.equals照样继承该行为 - 在 Lambda 或 Stream 中（如
filter(x -> Objects.equals(x.getStatus(), "ACTIVE"))），如果x.getStatus()可能返回null，这里就安全；但如果写成x.getStatus().equals("ACTIVE")，运行时崩
最常被跳过的一步：确认你比较的对象类型确实实现了合理语义的 equals——否则 Objects.equals 再安全也只是在“安全地返回错误结果”。
