Objects.requireNonNull 应用于明确契约“此处本不该为空”的场景，如构造函数、public方法参数校验及Stream/Optional链式调用前；推荐使用requireNonNull(T, String)重载以提升排查效率；禁用在private方法重复校验、循环体内或掩盖上游bug处。
Objects.requireNonNull 什么时候该用
它不是用来“兜底”所有可能为空的地方，而是明确表达“这里本就不该为空”的契约。比如方法参数校验、构造函数初始化、返回值非空断言——这些位置用了，后续代码就能放心跳过 null 判断。
常见错误现象：NullPointerException 在深层调用栈里抛出，堆栈信息难定位；或者靠 if (obj == null) 零散防御，逻辑被冲淡。
使用场景包括：
- 构造函数中强制检查依赖对象是否传入（避免实例处于半初始化状态）
- public 方法入口对关键参数做快速失败校验
- Stream 或 Optional 链式调用前，确保上游不会传入 null
Objects.requireNonNull 的三个重载怎么选
核心区别在提示信息的可控性，不影响功能，但影响排查效率。
立即学习“Java免费学习笔记（深入）”；
requireNonNull(T)：最简形式，抛出的异常消息是 "null"，适合内部快速校验；
requireNonNull(T, String)：推荐日常使用，能写明上下文，比如 "url must not be null"；
requireNonNull(T, Supplier<string>)</string>：延迟求值，适合拼接开销大或含副作用的提示（比如日志打点），但多数情况没必要。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
性能影响极小，JVM 对这类静态方法内联很友好；兼容性从 Java 7 开始就有，无顾虑。
和 if (obj == null) throw new NullPointerException() 有啥区别
语义更清晰，且避免手写错误。有人会漏写括号、错写异常类型（比如写成 IllegalArgumentException），或忘记加提示信息。
更关键的是：IDE 和静态分析工具（如 IntelliJ、ErrorProne）能识别 requireNonNull 并据此推断后续变量非空，从而减少误报警告；而手工 if 判断通常不被识别。
示例对比：
public void process(File file) {
if (file == null) throw new NullPointerException("file"); // 容易写错、难维护
// ...
}
换成：
public void process(File file) {
Objects.requireNonNull(file, "file"); // 工具链友好，意图明确
// ...
}
哪些地方用了反而坏事
别在以下位置滥用：
- private 方法内部反复校验同一个字段（字段已在构造时校验过）
- 循环体里对每次迭代的变量都调用（性能白耗，且掩盖设计问题）
- 作为“代替修复 bug 的临时补丁”，比如明知上游会传 null 却不改调用方，只在这里拦住
- 在返回值包装场景误用：比如
return Objects.requireNonNull(getFromCache())，其实应先修复getFromCache()本身可能返回 null 的逻辑
真正容易被忽略的是：它只解决“显式 null”，对空字符串、空集合、未初始化的数组等“逻辑空”完全无效。这类得靠业务规则判断，不能指望 requireNonNull。
