NullPointerException是非受检异常，因属RuntimeException子类而编译不检查，反映编码疏漏而非外部问题，需通过预防（如判空）而非捕获来解决。
NullPointerException 是 RuntimeException 的子类，编译器不强制处理，所以属于非受检异常。
它反映的是程序逻辑缺陷，不是外部不可控问题
Java 把异常分成两类，核心依据是“谁该负责”：外部资源出错（比如文件不存在、网络断开），开发者无法完全控制，所以用受检异常强制提醒；而空指针意味着你写了 obj.method() 却没确认 obj 是否为 null——这纯属编码疏漏，本该在写的时候就加判断。JVM 不拦着编译，就是告诉你：这不是环境问题，是 bug，得改代码，不是加 try-catch 就完事。
编译阶段完全放行，运行时才暴露
写 String s = null; int len = s.length();，javac 一声不吭，直接编译通过。只有真正执行到 s.length() 这一行，JVM 发现 s 指向的是无效地址，才抛异常。这种“编译不管、运行才炸”的行为，是非受检异常的典型特征。对比 new FileInputStream("a.txt")，编译器立刻报错要求处理，那就是受检异常。
设计上鼓励预防，而非兜底捕获
- 对 null 的合理使用本身没问题（如方法返回 null 表示“查无结果”）
- 问题出在后续未经检查就直接调用或访问
- 所以 Java 推荐做法是：明确 null 的语义 + 在使用前判空（比如用
Objects.requireNonNull()、Optional 或 if 判断） - 极少建议用 try-catch 包住可能空指针的代码块——那只是掩盖问题，不是解决问题
它和同类异常共享同一设计哲学
ArrayIndexOutOfBoundsException、IllegalArgumentException、ClassCastException 都和 NullPointerException 一样，继承自 RuntimeException，都是“写错了就该报”，而不是“可能发生，所以得防”。它们共同构成 Java 对“内部质量红线”的默认约束：不靠语法强制，而靠运行反馈倒逼开发者写出更严谨的逻辑。
