空指针异常是运行时逻辑错误，源于访问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 不是万能解药，但它强迫你面对“空”的可能性。它不是用来包装所有变量的，而是专用于方法返回值场景，比如查找、转换、链式计算。
立即学习“Java免费学习笔记（深入）”；
正确用法示例：
- 替代可能返回 null 的工具方法：
Optional<string> findName() { return Optional.ofNullable(db.loadName()); }</string> - 安全链式调用：
user.flatMap(User::getProfile).map(Profile::getEmail).orElse("no-email@example.com") - 避免
Optional.get()—— 它和直接调用一样危险；优先用ifPresent()、orElse()、orElseGet()
初始化与默认值：别让字段裸奔
实例字段、静态字段、局部变量若未显式初始化，在某些路径下就会是 null。尤其注意条件分支中遗漏赋值、try-catch 吞掉异常导致初始化失败等情况。
建议：
- 声明即初始化：如
private List<string> tags = new ArrayList();</string>，而非private List<string> tags;</string> - 用空集合/空字符串替代 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 当作一种合法状态去设计、校验和测试，异常自然就少了。
