objects.requirenonnull最合理用于构造函数、setter方法及public api入口处对必填引用参数的null校验，仅检查引用是否为null，不处理空字符串、空集合等逻辑空状态，抛出npe语义明确，支持链式调用与静态分析识别。
Objects.requireNonNull 用在哪种校验场景最合理
它只适合检查「调用方传入的引用是否为 null」，不是通用参数校验工具。比如构造函数、setter 方法、public API 入口处，对必填对象字段做快速拦截。别拿它去校验字符串内容是否为空、集合是否为空、数值是否越界——那些该用 StringUtils.isBlank()、CollectionUtils.isEmpty() 或手动判断。
- 只校验引用是否为
null，不处理空字符串、空集合、0 值等逻辑空状态 - 抛出的是
NullPointerException，语义明确：你传了个根本没初始化的对象 - 不适合在循环体内高频调用，有轻微开销（虽小但可避免）
为什么不能直接用 if (obj == null) throw new NullPointerException()
能用，但 Objects.requireNonNull() 更简洁、更一致、更容易被静态分析工具识别。更重要的是：它返回原对象，支持链式调用。
- 写
new Person(Objects.requireNonNull(name), Objects.requireNonNull(age))比分开判空再赋值少三行且无临时变量 - IDE 和 Checkstyle 等工具默认识别
requireNonNull为“已做非空保障”，后续使用不再报空指针警告 - 自定义错误消息时，
Objects.requireNonNull(obj, "name must not be null")比手写异常更紧凑
常见误用：把 requireNonNull 当成防御性复制或深校验
它不做任何拷贝、不递归检查内部字段、不验证子对象状态。传进一个非 null 但内部字段全为 null 的对象，它照收不误。
- ❌ 错误用法：
Objects.requireNonNull(user.getAddress())以为能保证地址对象里city不为 null —— 实际不能 - ❌ 错误用法：
Objects.requireNonNull(list)后直接list.get(0)—— list 可能是空集合，抛IndexOutOfBoundsException，和 null 无关 - ✅ 正确思路：null 校验只是第一道门，业务逻辑该做的边界检查（如 size、范围、格式）还得单独写
性能与兼容性要注意什么
Java 7 引入，所有现代 JDK 都支持；方法本身极轻量，但频繁调用仍建议只保留在关键入口点。
- 方法体就是一行
if (obj == null) throw ...，无反射、无正则、无额外对象创建 - Android 上注意：API level 19+ 才完整支持，低版本需自行 backport 或改用 Guava 的
Preconditions.checkNotNull() - 如果校验逻辑复杂（如多条件组合、日志记录、指标上报），别硬塞进
requireNonNull，拆成独立校验方法更清晰
事情说清了就结束
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
