Objects工具类不能防止空指针异常，但能提前暴露、安全处理并清晰表达：requireNonNull用于入口校验，equals统一判等，toString/hashCode安全兜底，nonNull简化过滤。
Objects 工具类不能“防止”空指针异常发生，但它能帮你把 NPE 暴露得更早、处理得更安全、写法更清晰。关键不在回避问题，而在掌控问题发生的时机和方式。
方法入口用 requireNonNull 做断言式校验
在 public 方法或构造函数的最开头，对关键参数强制非空——不是为了兜底，而是为了快速失败、精准定位。
- 用 requireNonNull(obj, "提示信息")，消息要具体，比如
"user.id cannot be null"，别写泛泛的"argument is null" - 只在校验入参时用，别在业务逻辑中间或返回值处理处滥用；它不修复 null，只是让崩溃发生在调用栈上层
- 避免链式调用中嵌套使用，例如
Objects.requireNonNull(getUser()).getName()—— 若getUser()返回 null，仍会炸，且掩盖了真正的问题源头
比较对象一律优先用 Objects.equals
只要两个对象中任一个可能为 null，就别直接调 a.equals(b) 或 a == b。语义相等 ≠ 引用相等，也 ≠ 能扛住 null。
- Objects.equals(a, b) 内部自动判空：都 null → true；一 null → false；都不 null → 调 a.equals(b)
- 适合场景：Map.get() 结果比对、JSON 反序列化字段比较、DTO 层对象判等
- 注意类型一致性：不要拿
Objects.equals(100, 100L)，Integer 和 Long 不等；基本类型比较请用==
日志、拼接、展示场景用 toString 和 hashCode 安全兜底
任何可能触发 obj.toString() 或 obj.hashCode() 的地方，只要 obj 可能为 null，就该换用 Objects 版本。
-
Objects.toString(obj, "默认值")：比三元运算
obj == null ? "null" : obj.toString()更简洁，也更适合日志模板 -
Objects.hashCode(obj)：返回 0（而非抛异常），适用于重写
hashCode()时字段可能为 null 的情况 - 避免在高频循环里反复调用这些方法——虽轻量，但有分支判断开销；已知非空时可直用原生方法
集合与流操作中搭配 nonNull 做过滤
当从 List、Stream 或 Optional 中提取对象后需进一步处理，用 Objects::nonNull 作为谓词，语义清晰又不易出错。
- Stream 过滤示例：
list.stream().filter(Objects::nonNull).map(User::getName).collect(...) - 比
filter(u -> u != null)更具可读性，也统一了团队风格 - 注意：它只做判空，不替代 Optional 的语义表达；复杂空值逻辑（如默认值、异常转换）仍建议用 Optional
