String.equals与Objects.equals区别详解

本文深入剖析了Java中String.equals()与Objects.equals()在处理null值时的本质区别：前者在接收方为null时必然抛出NullPointerException，是设计使然而非偶然；后者则通过内置的三步安全逻辑（引用相等→null检查→委托equals）优雅地规避空指针风险，支持任意类型、语义清晰且开销极小。文章不仅揭示了常见误用场景（如盲目链式调用、用常量兜底、“手动判空+equals”等权宜之计），更强调Objects.equals()的价值在于划清“调用安全”与“业务语义”的边界——它让代码更健壮、更简洁、更可维护，但绝不替代对null含义的业务思考和上游数据契约的坚守。

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() 包裹时，等于默许了它可能为空——这往往掩盖了上游数据污染或契约失效的问题。

终于介绍完啦！小伙伴们，这篇关于《String.equals与Objects.equals区别详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！