定位NullPointerException应先看堆栈最上层行号，逐个检查点号分隔的操作数谁为空；Java 14+可启用-XX:+ShowCodeDetailsInExceptionMessages获取精准提示；推荐用Optional明确表达可能为空的契约，并配合@Nullable注解与静态分析工具提前拦截。
看堆栈最上层的NullPointerException行号
Java抛出NullPointerException时，异常本身不带“哪个变量为空”的描述，但堆栈最顶端那行（通常是at com.example.Xxx.method(Xxx.java:23)）就是空指针实际发生的语句。重点不是看异常类名，而是看这一行里**谁在被调用或解引用**。
常见错误现象：堆栈指向list.size()、str.trim()、obj.getName()这类链式调用，但你只检查了obj，没意识到obj.getName()返回了null，接着又对它调用.toString()——真正空的是中间结果。
- 用IDE（如IntelliJ）点开堆栈行，直接定位到出问题的表达式左侧或右侧操作数
- 如果行内有多个点号（
.），从左往右逐个 mentally 拆解：是a空？还是a.b空？还是a.b.c空？ - 避免盲目加
if (x != null)——先确认到底哪一环空，否则可能掩盖真实问题
启用-XX:+ShowCodeDetailsInExceptionMessages（Java 14+）
Java 14起默认开启更精准的空指针提示，但某些运行环境（如旧版Tomcat、打包后的jar）可能关闭了它。开启后，异常信息会明确写出“Cannot invoke "toString()" because "user.address" is null”。
使用场景：本地开发或测试环境快速验证空值来源；CI流水线中捕获难以复现的NPE。
立即学习“Java免费学习笔记（深入）”；
- 启动参数加：
-XX:+ShowCodeDetailsInExceptionMessages - 注意兼容性：Java 13需加
--enable-preview，14+默认生效但部分JVM实现（如某些Alpine镜像里的OpenJDK）可能未同步支持 - 不解决根本问题，但能省掉70%的手动拆解步骤
用Optional替代裸null返回（尤其在Service/DAO层）
很多NPE源于方法契约不清：一个findUserById(long id)方法，文档没说找不到时返回null还是抛异常，调用方只能靠猜或试错。
性能影响极小（Optional是不可变对象，无状态，GC压力可忽略），但能强制调用方处理“不存在”分支。
- 不要在DTO、JSON序列化字段里用
Optional（Jackson默认不支持，会报JsonMappingException） - DAO层返回
Optional<user></user>比返回User更安全；Service层若必须返回User，应在判空后明确抛EntityNotFoundException - 慎用
Optional.get()——它和裸null一样危险；优先用ifPresent()、orElse()、orElseThrow()
静态分析工具提前拦截（SpotBugs + @Nullable注解）
靠运行时抛异常来发现问题太晚。用@Nullable/@NonNull配合SpotBugs（或IDE内置检查），能在编译期标出“这里可能传入null”“这里可能返回null但没判空”。
容易踩的坑：注解库选错（javax.annotation.Nullable在Java 9+默认不可用，推荐org.jetbrains.annotations.Nullable或androidx.annotation.Nullable），或只加在参数上却忘了加在返回值上。
- Gradle中加SpotBugs插件后，
@Nullable User getUser()+user.getName()会被标黄警告 - IDEA里默认启用
Constant conditions & exceptions检查，但对跨方法调用识别有限，需配合注解才准 - 别把
@NonNull当银弹——它不能阻止运行时null入参，只是让工具链能推理
空指针真正的复杂点不在“怎么修”，而在“为什么这个变量会是null”。查日志、看上游输入、翻调用链上下文，比加十个Objects.requireNonNull()更有用。很多人卡在“修复了A处NPE，B处又冒一个”，其实是没理清数据流源头的契约约定。
