空指针异常不该用try-catch拦截，因其是逻辑缺陷而非业务异常；应通过判空、Optional、工具类、静态检查等主动预防，仅在完全不可控外部源且有安全降级策略时谨慎使用。
空指针异常（NullPointerException）不该靠 try-catch 拦截来“优雅”处理——它本质是程序逻辑缺陷，不是可预期的业务异常。真正优雅的做法是预防，而非捕获。
为什么不该用 try-catch 拦截 NullPointerException
它不是设计用来被 catch 的运行时异常：JVM 抛出 NPE 是为了告诉你“这里本该有对象，但你忘了初始化或校验”。掩盖它等于掩盖 bug，后续可能引发更隐蔽的问题（比如错误计算、数据污染、状态不一致）。
常见误用场景：
- 把
user.getName().length()包进 try-catch，而不先判user != null - 在循环中对可能为 null 的集合调用
forEach，靠 catch 回避问题 - 把 NPE 当成“用户输入为空”的等价信号，混用业务语义
真正优雅的替代方案
1. 主动防御：前置判空 + Optional
立即学习“Java免费学习笔记（深入）”；
用 Objects.requireNonNull() 明确契约，或用 Optional 表达“可能为空”的语义：
// 明确拒绝 null，快速失败 String name = Objects.requireNonNull(user, "user must not be null").getName(); // 或者用 Optional 封装可能为空的结果 Optional<String> nameOpt = Optional.ofNullable(user).map(User::getName); nameOpt.ifPresent(System.out::println); // 安全消费
2. 工具类辅助：Apache Commons / Guava
减少样板代码：
-
StringUtils.isEmpty(str)替代str == null || str.trim().isEmpty() -
CollectionUtils.isNotEmpty(list)替代list != null && !list.isEmpty() -
MoreObjects.firstNonNull(a, b)提供默认值
3. IDE 和注解驱动静态检查
启用 @NonNull / @Nullable（如 JetBrains 注解或 JSR-305），配合 IDEA 或 SpotBugs，在编译期/静态分析阶段标出潜在空指针点，比运行时 catch 更早发现问题。
极少数可考虑 try-catch 的例外场景
仅限于：你**完全无法控制外部输入源**，且该异常发生后有明确、安全、无副作用的降级策略。
例如：
- 解析第三方 API 返回的 JSON 字段，字段文档模糊，SDK 又未做空保护，而你又必须兼容旧版本返回
- 反射调用某个可能不存在的方法（如适配多版本 SDK），且已有完备 fallback 逻辑
即便如此，也应：
- 单独 catch
NullPointerException，不笼统 catchException - 记录完整上下文日志（含入参、调用栈），便于后续修复
- 加注释说明为何此处必须 catch，以及计划何时移除
不复杂但容易忽略：优雅来自清晰的边界和主动的约束，不是兜底的侥幸。
