空指针异常应以预防为主，而非捕获：用Optional封装返回值、启用@NonNull/@Nullable注解、统一判空工具、构造器注入确保依赖不为空，并在单元测试中模拟null场景。
空指针异常（NullPointerException）是 Java 开发中最常见、最易触发的运行时异常之一。它不编译报错，却常在上线后突然爆发，导致服务中断或数据异常。避免它的核心不是“捕获”，而是“预防”——从编码习惯、工具支持和设计思路上提前堵住空值入口。
用 Optional 明确表达可能为空的返回值
方法返回 null 往往是为了表示“找不到”或“无结果”，但这把判断责任完全推给调用方，极易遗漏。改用 Optional
- 方法内部用
Optional.ofNullable(result)包装可能为 null 的返回值 - 调用方必须显式调用
.isPresent()、.orElse()或.ifPresent()，无法直接 .get() 而不检查 - 注意：不要把 Optional 用作字段类型或参数类型，仅用于返回值
启用并信任 @NonNull / @Nullable 注解
借助 IDE（如 IntelliJ）和编译器插件（如 Checker Framework 或 Lombok 的 @NonNull），可在编译期发现潜在空指针风险：
- 在参数、字段、返回值上标注
@NonNull，IDE 会提示未判空就直接使用的代码 - Lombok 的
@RequiredArgsConstructor配合@NonNull字段，会在构造时自动插入非空校验 - Spring Boot 2.5+ 默认启用
spring-boot-configuration-processor，对配置类属性也支持非空提示
集合与字符串操作前先判空再判内容
很多人只记得判 list != null，却忘了 list.isEmpty()；只判 str != null，却直接调 str.trim().length() —— 中间任意一环都可能炸：
立即学习“Java免费学习笔记（深入）”；
- 统一用
Objects.requireNonNull(obj, "xxx 不能为空")在入口快速失败，比静默 NPE 更易定位 - 字符串判空用
StringUtils.isBlank(str)（Apache Commons）或String.valueOf(str).trim().isEmpty()，避免 null 调用 - 集合操作前优先用
CollectionUtils.isNotEmpty(coll)，而非手写coll != null && !coll.isEmpty()
依赖注入与构造器初始化要“即用即检”
Spring 管理的 Bean 若存在循环依赖或配置遗漏，可能导致字段为 null；手动 new 的对象若忘记赋值，也会埋雷：
- 优先使用构造器注入（
@AllArgsConstructor(onConstructor_ = @__({@Autowired}))），让容器在创建时就确保依赖不为空 - 避免在 @PostConstruct 方法中才去校验字段，应把校验逻辑提前到构造器或 setter 中
- 单元测试里主动模拟 null 依赖（如 Mockito 的
@MockBean未初始化场景），验证是否抛出明确异常而非 NPE
基本上就这些。空指针不是靠 try-catch 拦住的，而是靠每一步都默认“它可能为空”，再用工具、约定和一点点防御性思维把它挡在执行之前。
