不应常规捕获NullPointerException，因其是程序逻辑缺陷信号，应优先修复根源；需通过参数校验、Optional、@NonNull等预防空指针，仅在不可控外部输入等极少数场景谨慎捕获并记录日志。
不建议主动捕获 NullPointerException 来返回友好提示，因为它通常是程序逻辑缺陷的信号，应优先修复根源，而非掩盖异常。
为什么不应常规捕获 NullPointerException
NullPointerException 是运行时异常（RuntimeException 子类），Java 设计初衷是让它暴露空指针问题，推动开发者在编码阶段就预防——比如校验入参、使用 Optional、启用编译期检查（如 IntelliJ 的 nullability 注解或 Lombok 的 @NonNull）。
盲目 try-catch 后返回“友好提示”，容易掩盖真实 bug，导致问题延迟发现，甚至引发更隐蔽的数据错误或状态不一致。
真正该做的：预防空指针
在关键位置主动防御，比事后捕获更可靠：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- 方法入口对必要参数判空并快速失败：
if (user == null) throw new IllegalArgumentException("用户信息不能为空"); - 用
Objects.requireNonNull()简洁断言：Objects.requireNonNull(name, "姓名不可为空"); - 集合/字符串操作前用
Objects.nonNull()或 Apache Commons Lang 的StringUtils.isNotEmpty()等工具方法 - 返回可能为空的对象时，明确用
Optional<t></t>包装，调用方必须显式处理空值场景
极少数可捕获的场景（慎用）
仅当空指针确实来自**不可控外部输入或遗留系统交互**（如解析第三方 JSON 字段缺失、反射调用未知类方法），且你确认该空值属于业务可接受的“正常缺省”情况时，才考虑捕获：
- 捕获后不静默吞掉，而是记录 warn 日志 + 明确返回业务语义清晰的提示：
try { result = obj.getName().trim(); } catch (NullPointerException e) { log.warn("对象obj为空，使用默认名称", e); return "未知用户"; } - 避免在大范围代码块（如整个 controller 方法）上 catch NPE，应聚焦到具体易空操作行附近
- 绝不把 NPE 捕获后转成 success 响应；应归为客户端错误（HTTP 400）或服务端缺省策略（如返回 null-safe 默认值）
统一异常处理（Spring Boot 示例）
若需全局兜底，应在框架层面做结构化处理，而非零散 catch：
- 用
@ControllerAdvice+@ExceptionHandler(NullPointerException.class)拦截未被捕获的 NPE - 在 handler 中记录 error 日志（含堆栈）、返回标准错误响应体（如
{"code":500,"msg":"系统内部错误，请联系管理员"}） - 同时配合监控告警，让这类异常成为推动代码质量改进的数据依据
