17370845950

空指针异常是运行时逻辑错误，源于访问null引用；需从源头防控、善用Optional、初始化默认值、覆盖空路径测试，并将null视为合法状态设计。

空指针异常（NullPointerException）不是语法错误，而是运行时因访问 null 引用的成员 触发的逻辑错误。它不报在写代码时，而藏在数据未就绪、校验被跳过、或默认值未设好的缝隙里。

明确谁可能为 null：从源头堵住隐患

方法参数、返回值、集合元素、外部输入（如 JSON 解析结果、数据库查不到的记录）、以及懒加载对象，都是高危 null 来源。不要假设“它肯定不为空”——Java 不强制你检查，但 JVM 会毫不留情地抛异常。

建议：

• 用 @NonNull（JetBrains 注解）或 @NotNull（JSR-305）标注参数和返回值，配合 IDE 提示提前发现风险
• 对外部接口调用（如 map.get(key)、list.get(0)）一律先判空，尤其 Optional.ofNullable() 可让判空更语义化
• 构造函数中对关键字段做非空校验，例如：Objects.requireNonNull(name, "name must not be null")

善用 Optional：把“可能为空”显式化

Optional 不是万能解药，但它强迫你面对“空”的可能性。它不是用来包装所有变量的，而是专用于方法返回值场景，比如查找、转换、链式计算。

正确用法示例：

• 替代可能返回 null 的工具方法：Optional findName() { return Optional.ofNullable(db.loadName()); }
• 安全链式调用：user.flatMap(User::getProfile).map(Profile::getEmail).orElse("no-email@example.com")
• 避免 Optional.get() —— 它和直接调用一样危险；优先用 ifPresent()、orElse()、orElseGet()

初始化与默认值：别让字段裸奔

实例字段、静态字段、局部变量若未显式初始化，在某些路径下就会是 null。尤其注意条件分支中遗漏赋值、try-catch 吞掉异常导致初始化失败等情况。

建议：

• 声明即初始化：如 private List tags = new ArrayList();，而非 private List tags;
• 用空集合/空字符串替代 null：Collections.emptyList()、StringUtils.EMPTY 比 null 更安全、更易遍历
• 记录日志时避免 log.info("user: {}", user.getName()) —— 若 user 为 null，toString() 调用前就已崩溃；改用 log.info("user: {}", Objects.toString(user, "null"))

单元测试覆盖空路径：让问题暴露在上线前

很多 NPE 出现在边界场景：数据库查无结果、HTTP 接口返回 404、前端传参缺失。这些往往不会在 happy path 测试中浮现。

建议：

• 为每个 public 方法编写至少一个 输入为 null 的测试用例，验证是否合理处理（抛自定义异常 / 返回默认值 / 快速失败）
• 用 Mockito 模拟依赖返回 null，验证主逻辑健壮性，例如：when(service.findUser(123)).thenReturn(null)
• 开启 IDE 的 null 分析（IntelliJ 的 “Enable @Nullable/@NotNull annotation-based checking”），它能在编码阶段标出潜在空引用

不复杂但容易忽略：NPE 的根因从来不是“Java 不够智能”，而是我们把“假设不为空”当成了默认前提。把 null 当作一种合法状态去设计、校验和测试，异常自然就少了。