NPE本质是逻辑缺陷而非意外事件，需通过预防规避：对参数用Objects.requireNonNull校验、字符串比较采用"常量".equals(变量)、返回值优先用Optional封装、集合统一返回空集合而非null、配合@NonNull注解与单元测试覆盖null路径。
空指针异常（NullPointerException，简称 NPE）不是靠“捕获”来解决的，而是靠“预防”——它本质是程序逻辑缺陷，不是意外事件。真正健壮的 Java 代码，绝大多数 NPE 都应在运行前就被规避掉。
提前判空与防御性检查
最直接有效的方式是在使用对象前确认其非空。这不是啰嗦，而是明确表达意图：
- 对方法参数做非空校验：用 Objects.requireNonNull(obj, "msg")，一旦为 null 立即抛出带提示的
NullPointerException，比静默崩溃更利于定位 - 对返回值不确定的方法调用后立即检查：比如从 Map 获取值、数据库查询结果、远程接口响应，别假设“它一定有”
- 字符串比较避免调用未知对象的
equals()：写成 "known".equals(unknown)，而不是unknown.equals("known")，前者安全，后者一 null 就炸
善用 Optional 明确空值语义
Optional 不是万能解药，但它是把“可能为空”显式化、强制处理的利器：
- 方法返回值用 Optional<T> 包装，例如
Optional<user> findUserById(Long id)</user>，调用方必须面对“有没有”的事实 - 链式调用不再写
obj.getA().getB().getC()这种高危操作，改用Optional.ofNullable(obj).map(A::getB).map(B::getC).orElse(null) - 避免滥用
get()；优先用orElse()、orElseGet()或ifPresent()，让空值处理逻辑清晰可见
设计层面减少 null 出现机会
很多 NPE 其实源于 API 设计妥协。从源头降低风险更高效：
立即学习“Java免费学习笔记（深入）”；
- 集合类方法一律返回空集合（Collections.emptyList()），而非
null；调用方无需额外判空即可遍历 - 包装类型字段慎用自动拆箱：
Integer age直接赋给int变量会触发 NPE；要么用age == null ? 0 : age，要么改用基本类型或 Optional - 构造器和 setter 中对必填字段做非空校验，失败就拒绝创建对象，不留下“半残”实例
- 用 @NonNull / @Nullable 注解（配合 IDE 或 Lombok）在编译期提示潜在空值，比运行时报错早得多
工具与习惯辅助长期防控
单靠人盯代码容易遗漏，借助工程化手段形成习惯：
- 在 CI 流程中集成静态分析工具（如 SpotBugs、SonarQube），配置 NPE 相关规则，把隐患挡在上线前
- 单元测试覆盖边界场景：特别验证输入为 null、集合含 null 元素、级联对象中间为 null 等情况
- 日志中记录关键对象是否为 null（如远程调用返回值），不只记录“发生了 NPE”，更要记录“哪个环节开始丢了数据”
