应主动用Objects.requireNonNull()校验参数、用Optional封装可能为空的返回值、用@NonNull等注解做静态检查，并警惕自动拆箱和字符串拼接中的隐式null。
用 Objects.requireNonNull() 主动拦截 null
空指针异常（NullPointerException）多数发生在方法内部对参数或字段做非空假设时。与其等运行时报错，不如在入口处显式校验。Java 7+ 提供的 Objects.requireNonNull() 是最轻量、语义最清晰的防御手段。
它会在传入 null 时立即抛出带消息的 NullPointerException，堆栈指向调用点而非深层访问点，排查效率高。
- 适用于构造函数、
public方法参数校验，尤其当该值后续会被多次解引用时 - 不要用于高频循环内——虽开销极小，但无谓调用会累积；优先用静态分析或契约约定
- 可配合自定义消息：
Objects.requireNonNull(name, "name must not be null")，比默认消息更利于定位
public class User {
private final String name;
public User(String name) {
this.name = Objects.requireNonNull(name, "name cannot be null");
}
}
用 Optional 封装可能为空的返回值
Optional 不是用来“避免所有 null”的银弹，而是明确表达“这个值可能不存在”的契约。它强制调用方处理空分支，防止 get() 直接裸调用导致二次 NPE。
关键原则：只对**方法返回值**使用 Optional，不要用作字段、参数或集合元素——这违背其设计意图，且会增加 GC 压力和可读性负担。
立即学习“Java免费学习笔记（深入）”；
- 正确场景：数据库查询可能无结果、配置项可能未设置、异步结果尚未到达
- 错误场景：
private Optional<string> name;</string>或void process(Optional<user> user)</user> - 链式调用时优先用
map()/flatMap()而非先isPresent()再get()
public Optional<User> findUserById(Long id) {
return userRepository.findById(id); // 返回 Optional 已体现语义
}
// 调用方必须显式处理
userRepo.findUserById(123L)
.map(User::getName)
.orElse("anonymous");
用 @NonNull 和 IDE/编译器做静态检查
运行时防御总有遗漏，静态检查能在编码阶段暴露风险。虽然 Java 标准库没有内置 @NonNull，但主流工具链支持良好：
- IDEA 默认识别
@org.jetbrains.annotations.NotNull，对参数、返回值、字段标上后，未判空就解引用会标黄警告 - Lombok 的
@NonNull字段注解会在生成的构造/Setter 中自动插入Objects.requireNonNull() - Checker Framework 的
@NonNull可在编译期报错，但需额外配置，适合高可靠性项目
注意：这些注解本身不产生运行时行为，纯属“提示+检查”。若关闭检查或忽略警告，照样会 NPE。
警惕自动拆箱和字符串拼接中的隐式 null
这两类是 NPE 高发但容易被忽略的场景，因为表面看没写 .xxx 这样的解引用操作。
- 自动拆箱：
Integer i = null; int j = i; // NPE 在赋值时触发，不是在 i.toString() - 字符串拼接：
String s = null; String t = "value=" + s; // 实际调用 s.toString()，NPE - 数组/集合初始化：用
Arrays.asList(null)创建含 null 元素的列表，后续遍历时再触发
这类问题无法靠 Optional 或 @NonNull 完全覆盖，需结合单元测试覆盖边界值，并在日志中留意 "null" 字符串是否意外出现——那往往是上游未处理 null 的线索。
