空指针异常（NPE）是Java中最常见运行时错误，需通过设计、编码、调用全程防御来避免；关键措施包括识别null源头、使用@NonNull/Optional/Objects.requireNonNull、统一接口契约、覆盖null路径测试及渐进式重构。
空指针异常（NullPointerException，NPE）是Java开发中最常见、最易忽视的运行时错误。它不发生在编译期，却常在上线后突然爆发——不是因为代码写错了逻辑，而是忘了“这个对象到底有没有被初始化”。彻底避免NPE，靠的不是事后try-catch，而是从设计、编码到调用全程建立防御意识。
明确所有可能为null的源头
很多NPE其实源于对“谁会返回null”缺乏预判。以下几类场景必须主动检查：
- 方法返回值：尤其是第三方库、DAO层查询结果（如red">Optional.empty()、Map.get()、Collection.stream().findFirst().orElse(null)）
- 外部输入：HTTP参数、JSON反序列化字段、配置文件读取值（如System.getProperty("xxx")）
- 构造过程失败：Builder模式中必填字段未设、依赖注入失败（Spring中@Autowired字段为null常因未被IoC容器管理）
- 数组与集合元素：如list.get(0)前未校验size，或数组项本身为null
用工具和语法提前拦截null
别等运行时报错才处理。现代Java提供了多种静态/语法级防护手段：
- @NonNull / @Nullable 注解：配合IDE（IntelliJ/Eclipse）或Lombok（@RequiredArgsConstructor、@NonNull字段），让编译器提示潜在风险
-
Optional 类型契约化：把“可能为空”的语义显式写进方法签名，例如：
public OptionalfindUserById(Long id) ，调用方就必须用isPresent()或orElseThrow()处理 -
Objects.requireNonNull()：在方法入口快速失败，比后续NPE堆栈更清晰
public void process(User user) { Objects.requireNonNull(user, "user must not be null"); ... } - Java 14+ 的 NullPointerException增强：开启-XX:+ShowCodeDetailsInExceptionMessages，能直接看到哪一行、哪个变量为null（如a.b.c.toString() → c is null）
约定接口与协作规范
NPE常出现在模块边界。与其各自防御，不如统一契约：
立即学习“Java免费学习笔记（深入）”；
- 对外API返回集合，永远不返回null，改用空集合（Collections.emptyList()）
- DTO/VO字段全部使用包装类型（Integer而非int），并明确文档说明哪些字段可为null
- 内部服务间调用，强制要求FeignClient或Dubbo接口返回Result
封装体，状态码+data分离，避免裸null透传 - 单元测试覆盖null路径：每个public方法至少写一条传入null参数的测试用例
重构老代码的实用技巧
面对遗留系统，不必重写，可渐进加固：
- 用IDE批量替换if (obj != null)为Objects.nonNull(obj)（语义更清晰，且支持静态分析）
- 将频繁判空的链式调用（如user.getAddress().getCity()）抽取为工具方法，内部用Optional.ofNullable()安全导航
- 对DAO层，用MyBatis-Plus的@TableName(autoResultMap = true) + @TableField(fill = FieldFill.INSERT)减少手动赋null
- 日志中打印可疑对象前，先用String.valueOf(obj)代替obj.toString()，避免日志本身触发NPE
基本上就这些。NPE不是bug，是信号——提醒你某个假设没被验证。防御式编程不是加一堆if，而是让null的意图可见、流转可控、失败可测。写完一行代码，多问一句：“它有没有可能是null？如果真是null，现在发现还是上线后发现？”
