NullPointerException 总在运行时才报，因为 Java 仅在调用 null 引用的方法、访问其字段或数组长度时抛出，编译器不检查空值，JVM 也不提前拦截。
为什么 NullPointerException 总在运行时才报？
因为 Java 只在真正调用一个为 null 的引用的方法、访问其字段，或进行数组长度读取等操作时，才会抛出 NullPointerException。编译器不检查引用是否为空，JVM 也不做提前拦截——它默认你“知道自己在做什么”。
常见触发点包括：
-
obj.toString()中obj == null -
list.size()中list是null而非空集合 -
str.length()中str是null，不是"" - 自动拆箱：如
Integer i = null; int j = i;→ 拆箱触发 NPE
怎么用 Objects.requireNonNull 主动防御？
它不是用来“捕获”异常的，而是把隐式 NPE 提前到明确位置，并附带可读提示。适合校验方法入参、构造函数参数、关键依赖注入点。
示例：
立即学习“Java免费学习笔记（深入）”；
public UserService(UserDao userDao) {
this.userDao = Objects.requireNonNull(userDao, "userDao must not be null");
}
注意点：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 只在校验失败时抛
NullPointerException，不是IllegalArgumentException - JDK 7+ 才有；若需兼容旧版本，可用
if (obj == null) throw new NullPointerException(...) - 不要滥用在循环体或高频路径里——有轻微开销（但通常可忽略）
Optional 能彻底解决 NPE 吗？
不能。它只是把“是否为空”的判断显式化、强制化，但误用反而更易引发 NPE：
-
optional.get()在空值时仍抛 NPE -
optional.map(...).orElse(null)把问题又藏回了null - 过度包装：比如对本地变量、已知非空对象套
Optional，增加理解成本
推荐场景只有两个：
- 作为方法返回值，表示“可能无结果”（如
findById(id)） - 链式处理中避免嵌套
if (x != null)（如user.getAddress().getCity()→user.flatMap(User::getAddress).map(Address::getCity)）
IDE 和 Lombok 怎么帮你在编码阶段发现隐患？
现代 IDE（IntelliJ / Eclipse）能基于静态分析标出潜在 NPE 路径，但前提是启用相关检查项并配合注解。
关键实践：
- 给参数/字段加
@Nullable/@NotNull（JetBrains 注解或 JSR-305），IDE 会据此推断 - Lombok 的
@NonNull会在生成的构造/Setter 方法中自动插入Objects.requireNonNull - 启用编译期检查：Maven 中配
checkerframework或errorprone插件，比运行时早几轮发现问题
真正容易被忽略的是：团队协作中，很多人只看方法签名，不看 Javadoc 或注解含义，导致调用方仍传 null —— 这时候再强的工具也救不了设计层面的模糊契约。
