空指针异常是运行时逻辑错误，防范关键在于提前判空、用Objects.requireNonNull校验参数、以Optional显式表达可选性、初始化集合与对象、配合注解编译期预警。
Java 中的空指针异常（NullPointerException，简称 NPE）不是语法错误，而是运行时因试图对 null 引用执行“需要对象实例”的操作而触发的逻辑错误。它不难理解，但极易在链式调用、集合遍历、方法返回值处理等场景中悄然发生。关键不在“怎么捕获”，而在“怎么提前挡掉”。
明确判空：最直接也最容易被忽略的防线
很多 NPE 其实只需一行 if (obj != null) 就能避免，尤其在以下位置：
- 调用外部方法返回值前（如
getUserById(id)可能返回null） - 访问嵌套对象属性前（如
user.getAddress().getCity()中任一环节为null都会崩） - 使用集合或数组元素前（如
list.get(0).toString()，但list或其首元素可能为null）
善用 Objects.requireNonNull：把问题拦在入口
适用于方法参数校验，让错误暴露得更早、更清晰：
- 在构造器或公有方法开头强制检查必要参数：
Objects.requireNonNull(name, "name 不能为空") - 抛出的异常带明确定义的提示信息，便于调试和协作
- 比裸写
if更简洁，且语义明确——这不是可选逻辑，是契约要求
拥抱 Optional：让“可能为空”显性化
Optional 不是用来包装所有变量的，而是专为方法返回值设计的契约表达工具：
立即学习“Java免费学习笔记（深入）”；
- 把
findUser(Long id)改成Optional<User> findUser(Long id)，调用方必须考虑“找不到”的情况 - 用
map()、filter()、orElse()等链式操作替代层层if，代码更函数化、更安全 - 避免滥用：
Optional<String> name = Optional.ofNullable(user.getName())是合理用法；但把字段声明为Optional<String>属于反模式
初始化与设计习惯：从源头减少 null 出现
预防永远比补救高效：
- 集合类优先返回空集合而非
null：return Collections.emptyList()而非return null - 避免在业务方法中随意返回
null，改用状态枚举或空对象（如User.EMPTY） - 成员变量尽量在声明或构造器中初始化，减少默认
null状态 - 使用 Lombok 的
@NonNull或 JetBrains 的@NotNull注解配合 IDE 提示，在编译期预警潜在空值
空指针异常本身不复杂，但它背后反映的是对数据契约的模糊认知。真正有效的处理，是把“是否可能为空”变成接口设计的一部分，而不是靠运行时一次次侥幸躲过崩溃。
