NullPointerException 在运行时才报错，因 Java 编译器不检查 null，仅依赖类型匹配；需通过显式判空、Objects.requireNonNull() 或 Optional 显式处理可空性。
为什么 NullPointerException 总在运行时才报错
Java 编译器不会检查引用是否为 null，只要类型匹配就放行。比如 String s = null; s.length(); 能顺利编译，但执行到 length() 时 JVM 才发现 s 是空引用，抛出 NullPointerException。这是静态类型语言的固有限制——类型系统不建模“可空性”。@Nullable 注解（如 JetBrains 或 Checker Framework 提供）仅用于 IDE 提示或额外检查，不改变 JVM 行为。
如何在调用前安全判断 null
最直接的方式是显式判空，但要注意判空逻辑必须覆盖所有可能为 null 的入口点，尤其是方法参数、返回值、集合元素和外部输入（如 JSON 反序列化结果）。常见疏漏包括：
- 只检查了对象本身，没检查其嵌套字段（如
user.getAddress().getCity()中getAddress()返回null） - 用了
== null判空，但对包装类（如Integer）误用.equals(null)（会 NPE） - 在
if分支里忘了处理else，导致后续代码仍可能操作null
推荐写法：
if (str != null && !str.trim().isEmpty()) {
process(str);
}
注意：多个条件用 &&（短路与），确保左侧为 false 时右侧不执行；避免用 &（非短路），否则仍可能触发 NPE。
立即学习“Java免费学习笔记（深入）”；
用 Objects.requireNonNull() 主动暴露问题
当某个参数**绝不应为 null**（比如构造函数入参、核心业务逻辑的必填字段），与其让 NPE 在深层调用栈中随机爆发，不如在入口处立即失败。这能缩短定位路径，也符合“fail-fast”原则。
Objects.requireNonNull() 不仅判空，还支持自定义提示消息：
public User(String name, Integer age) {
this.name = Objects.requireNonNull(name, "name must not be null");
this.age = Objects.requireNonNull(age, "age must not be null");
}
对比手动 if (x == null) throw new NullPointerException(...)，它更简洁、语义更明确，且 JDK 9+ 还提供了 requireNonNullElse() 和 requireNonNullElseGet() 处理默认值场景。
用 Optional 封装可能为空的返回值
Optional 不是用来消灭 NPE 的银弹，而是**把“可能为空”这个契约显式编码进类型系统**。它强制调用方思考“如果没有值怎么办”，而不是侥幸跳过判空。
适用场景有限：仅适合**方法返回值**（不能用于字段、参数、集合元素）。错误用法包括：
- 把
Optional<user></user>当作User字段存进实体类（违反设计初衷，且序列化/ORM 易出问题） - 链式调用中混用
.get()（绕过安全机制，等于白用） - 用
Optional.of(null)（直接抛 NPE，应改用ofNullable()）
正确示范：
public Optional<String> findEmailByUserId(Long id) {
return Optional.ofNullable(userDao.findById(id))
.map(User::getEmail);
}
// 调用方必须处理空情况
String email = findEmailByUserId(123L).orElse("default@example.com");
真正难的是统一团队认知：不是所有“可能为空”的地方都该上 Optional，比如 DAO 层查不到记录返回 null 更符合直觉，而 Service 层封装后返回 Optional 才体现业务语义。
空指针的本质不是语法错误，而是契约断裂——你假设某个引用有值，但它没有。防御的关键不在技巧堆砌，而在清楚每个变量的生命周期、来源和责任边界。哪怕用了 Optional 和注解，若上游传入 null 时不校验，下游照样崩。
