空指针异常不应依赖全局捕获兜底，而应通过入口校验、optional返回值、静态检查三道关卡在开发期根治；@controlleradvice可有限拦截controller层npe，需记录日志并返回带提示的400响应。
空指针异常（NullPointerException，NPE）不该靠全局捕获来兜底，但作为最后一道防线，它确实可以被统一拦截——前提是明确它的定位：这是兜底措施，不是替代源头防控的方案。
用 @ExceptionHandler 拦截 NPE 是可行的，但要谨慎设计
Spring 的 @ControllerAdvice 配合 @ExceptionHandler(NullPointerException.class) 能捕获控制器层抛出的 NPE，返回结构化错误响应。但它只管“从 Controller 方法体里直接或间接抛出”的 NPE，不处理：
- Filter、Interceptor 中的空指针
- 异步线程（如
@Async）里的 NPE - 定时任务、初始化代码块中的 NPE
- 数据库操作、JSON 序列化等框架内部触发的 NPE（通常已由框架自身处理）
所以拦截范围有限，仅覆盖 MVC 请求链路的末端。
拦截时不要掩盖问题，而要提供可排查线索
直接返回“数据为空”或“系统错误”会丢失关键信息。建议在响应中保留原始异常消息，并附加堆栈摘要（生产环境需脱敏）：
- 记录完整日志（含 traceId），确保能关联请求上下文
- 响应体中返回简洁提示，例如：
"npe: user.name is null" - 状态码建议用
400 Bad Request（语义上属于客户端传参/数据契约问题），而非 500
真正防 NPE 的重点不在拦截，而在拦截前的三道关卡
全局拦截只是补救手段，以下才是根治路径：
-
入口校验：所有 public 方法参数用
Objects.requireNonNull()显式声明非空契约 -
返回值建模：对可能为空的查询结果（如
findById），统一返回Optional<t></t>，强制调用方处理分支 -
静态检查：启用 IDE 的
@NonNull/@Nullable注解 + Lombok@RequiredArgsConstructor，把空值风险拦在编码阶段
这些措施能让绝大多数 NPE 在开发期就暴露，而不是等到运行时才靠全局异常处理器去“接住”。
一个轻量但实用的 NPE 拦截示例
如果仍需拦截，推荐这样写（使用 @RestControllerAdvice）：
- 只拦截 NPE，不放在
Exception.class的兜底逻辑里（避免干扰其他异常分类） - 响应格式与业务异常一致，例如封装为
ErrorResponse对象 - 日志记录包含请求路径、方法名、异常消息，方便快速定位
不需要过度包装或重试逻辑——NPE 是程序逻辑缺陷，修复代码比增强拦截更重要。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
