Spring Boot中NPE防控核心是编译期拦截：Spring Boot 4起采用JSpecify规范，通过@NullMarked设包默认非空、@Nullable标注例外，并配合IDE或NullAway实现未判空即编译报错。
Spring Boot 中处理空指针异常，核心思路已从“出了问题再修”转向“还没运行就拦住”。不是靠堆栈排查或加一堆 if (obj != null)，而是用编译期检查 + 显式契约 + 工具协同，把 NPE 消灭在源头。
启用编译期空安全（Spring Boot 4 默认机制）
Spring Boot 4 起全面采用 JSpecify 规范，实现“默认非空、例外标注”：
- 在包根目录下新建
package-info.java，添加@NullMarked—— 整个包内所有参数、返回值、字段默认不可为空 - 只对真正可能为空的地方，显式加上
@Nullable（如数据库查不到时返回 null 的 Service 方法） - 配合 IDE（如 IntelliJ）或静态分析工具（如 NullAway），未判空就直接调用
@Nullable类型，编译报错，不等运行
规范依赖注入场景
很多 NPE 其实发生在 Spring 容器没管到的地方：
- 启动类
main方法中不能直接用@Autowired，需通过ApplicationContext手动获取 Bean - 拦截器（
HandlerInterceptor）、Filter、Listener 等组件初始化早于 Spring 上下文，@Autowired无效；应注入ApplicationContext，再用getBean() - 测试类中记得加
@SpringBootTest或@ContextConfiguration，否则@Autowired字段为 null
数据库与 ORM 层防坑要点
JPA/MyBatis-Plus 查询结果为空是常态，别假设一定有值：
- JPA Repository 方法如
findById()返回Optional，务必用isPresent()或orElse()处理，别直接.get() - MyBatis-Plus 的
selectOne()可能返回 null，调用前必须判空；复杂关联查询注意@ManyToOne是否触发了延迟加载失败 - 实体间外键字段为 null 时，链式调用（如
billing.getAccountId().getName()）极易 NPE，建议用Objects.toString(billing.getAccountId()?.getName(), "")或拆成多步校验
运行时兜底与可观测性
即便做了编译期防护，生产环境仍需快速定位漏网之鱼：
- 开启 DEBUG 日志，重点关注
o.s.b.f.s.DefaultListableBeanFactory和o.s.c.a.AnnotationConfigApplicationContext，确认 Bean 是否成功注册 - 在关键入口方法加
Assert.notNull(param, "param must not be null")，让问题暴露得更早、更明确 - 使用 IDEA 的 “Analyze Stack Trace” 功能，粘贴线上 NPE 堆栈，自动跳转到源码出错行
