不应使用 try-catch 处理 NullPointerException，因其是可预防的逻辑缺陷，掩盖问题会推迟发现、破坏 fail-fast 原则并引入隐藏错误；应通过参数校验、Optional、静态检查等源头预防。
不建议专门用 try-catch 去捕获 NullPointerException（NPE），它本质上是程序逻辑缺陷，不是需要“捕获并恢复”的运行时异常，而应通过预防和设计来避免。
为什么不该用 try-catch 处理 NullPointerException
NullPointerException 是 unchecked 异常，JVM 不强制要求捕获；更重要的是，它通常表明代码存在空值未校验、对象未初始化、方法返回 null 未预期等可修复的 bug。用 catch 掩盖问题，反而会推迟发现、增加调试难度，甚至导致隐藏的数据不一致或业务逻辑错误。
- 掩盖真实缺陷：catch 后若仅打印日志或忽略，调用方可能误以为操作成功
- 破坏 fail-fast 原则：本该立即暴露的问题被延迟到后续更深层逻辑才崩溃
- 性能无意义开销：NPE 是编程错误，不是正常流程分支，不值得为它加异常处理路径
真正该做的：在源头预防 NPE
把精力放在“不让 null 流入危险位置”，比写一堆空指针 catch 更有效、更健壮：
- 方法参数校验：使用
Objects.requireNonNull(obj, "msg")或 Spring 的@NotNull+ AOP 校验 - 返回值约定明确：工具类方法（如
Map.get()）优先返回Optional，而非可能为 null 的原始值 - 成员变量初始化：用 final 字段 + 构造器注入，避免字段为 null
- 使用 IDE 和静态检查：启用 IntelliJ 的 nullability 注解（
@Nullable/@NonNull），配合 FindBugs / SpotBugs 或 SonarQube 提前告警
极少数可接受 try-catch NPE 的场景
仅当满足全部条件时才考虑：外部不可控、无替代 API、且失败可安全降级。例如：
立即学习“Java免费学习笔记（深入）”；
- 调用遗留第三方库，文档未声明是否返回 null，且无非空重载方法，又必须兼容其行为
- 解析动态 JSON 或 XML 字段（如 Jackson 反序列化未标注
@JsonInclude(Include.NON_NULL)的字段），且该字段缺失属于合法业务状态 - 此时应 catch 后明确处理（如设默认值、跳过当前项、记录结构化告警），而非泛泛吞掉异常
替代 try-catch 的更优方案
用现代 Java 特性主动管理 null，语义清晰、类型安全：
-
Optional<t></t>：表达“可能无值”的意图，强制调用方处理空情况（ifPresent()、orElse()、map().orElse(null)） - 空安全方法链：如
str?.length()（虽 Java 不支持，但可用Optional.ofNullable(str).map(String::length).orElse(0)模拟） - Lombok 的
@NonNull自动生成 null 检查（构造器/Setter 中抛 IllegalArgumentException） - Guava 的
Preconditions.checkNotNull()：失败时抛出带上下文的 IAE，比 NPE 更易定位
