string.equals() 遇 null 必抛 nullpointerexception；objects.equals() 安全处理 null，a 和 b 均为 null 时返回 true，仅一个为 null 时返回 false，且不依赖类型。
String.equals() 遇到 null 就崩，不是“可能”，是必然
只要 str 是非 null，调用 str.equals(other) 是安全的；但一旦 str 为 null，立刻抛出 NullPointerException。这不是边界 case，而是设计使然——String.equals() 从不检查自身是否为 null，它假设调用者已确保接收方非空。
常见错误场景：
- 从 Map.get()、JSON 解析、数据库查询结果中拿到的字符串字段未判空就直接
.equals() - 方法参数声明为
String，但调用方传了null，而你忘了 guard - 链式调用如
user.getName().equals("admin")，getName()返回 null 时整行崩溃
Objects.equals() 的 null 判断逻辑是硬编码在 JDK 里的
Objects.equals(a, b) 内部只做三件事：先检查 a == b（同一对象），再检查 a == null || b == null，最后才调用 a.equals(b)。这意味着无论 a 和 b 哪个是 null，都不会触发 NPE。
关键细节：
- 当
a和b都为null时，返回true（语义上“两个空值相等”） - 当仅一个为
null时，返回false（不抛异常，也不尝试调用null.equals()） - 它不要求参数类型一致，
Objects.equals("abc", 123)合法且返回false
别用 String.equals() 去“假装”处理 null
有人写 str != null && str.equals("value")，这能工作，但属于手动补救，不是设计层面的安全。问题在于：
- 重复判断：每个用到的地方都要写两段逻辑，易漏、难维护
- 语义割裂：把“相等性判断”拆成“非空检查 + 相等调用”，破坏表达意图
- 类型局限：如果变量类型是
Object或泛型T，你就没法用String.equals()了
更糟的是，有人误写成 "value".equals(str) 来规避 NPE——这确实不会崩，但属于“用常量兜底”的权宜之计，可读性差，且无法推广到非 String 类型。
Objects.equals() 不是万能的，但它划清了责任边界
它解决的是“调用时的空安全”，不是“业务逻辑中的空含义”。比如：
-
Objects.equals(user.getEmail(), "test@example.com")在 email 为 null 时不报错，但你要想清楚：null 邮箱算“等于”某个具体邮箱吗？业务上很可能不算，这时应显式处理 null 分支 - 它不替代参数校验：
Objects.equals()不会阻止你把null存进集合或传给下游，只是让这次比较不炸 - 性能差异几乎可忽略：一次引用比较 + 两次 null 检查，比手写
if还轻量
真正容易被忽略的点是：当你把一个本该非空的字段（如主键 ID）也用 Objects.equals() 包裹时，等于默许了它可能为空——这往往掩盖了上游数据污染或契约失效的问题。
