javanull异常全面剖析NullPointerException的成因与常见形态_网络技术

NullPointerException在运行时才抛出，因为编译器只检查类型合法性而不校验null值，null是唯一可赋给任意引用类型的合法值，导致s.length()等调用在执行时崩溃。

因为null是Java中唯一能赋给任意引用类型的“合法值”，编译器只校验类型匹配，不校验是否为null。它让String s = null;完全合法，但s.length()一执行就崩——这不是语法错，是语义错。

真正危险的是那些“看起来没问题”的链式调用：user.getAddress().getCity().toUpperCase()。只要中间任一环节返回null

（比如getAddress()查不到地址），整个链就立刻触发NPE，而堆栈只报最后一行，你得倒推哪一环空了。

它比手写if (obj == null) throw new NullPointerException()更简洁，关键是能带明确定制消息，且JVM在某些版本（Java 14+启用-XX:+ShowCodeDetailsInExceptionMessages）下会直接标出哪个变量为空。

实操建议：

所有public方法入口，对必填参数强制校验：Objects.requireNonNull(userId, "userId must not be null")
不要只在校验参数上用——构造函数、Builder的build()方法里也加，把问题拦在对象创建阶段
避免滥用：内部工具方法若明确允许null（如“兼容旧逻辑”），就别硬加，否则反而掩盖真实空路径

很多人只记得判list == null，却忘了list.get(0)可能返回null，或者stream().findFirst().orElse(null)的返回值直接进下一行调用——这和对象未初始化一样致命。

典型翻车现场：

List users = dao.findUsers(); for (User u : users) { System.out.println(u.getName()); } —— 若users为null，增强for直接NPE；若users非空但含null元素，循环到那个位置仍NPE
String[] arr = config.getStringArray("roles"); if (arr.length > 0) {...} —— arr为null时.length就挂了
Map.get()返回null不等于键不存在——可能是键存在但值就是null，要用containsKey()或getOrDefault()区分

包装类自动转基本类型（拆箱）时，如果对象是null，会立即抛NPE，而且错误行号容易误导人：

Integer count = null;
int c = count; // 看似简单赋值，实际触发NPE

equals()也是重灾区——str.equals("abc")在str为null时必崩，但"abc".equals(str)安全，因为字面量字符串不可能为null。

永远用常量.equals(变量)，而不是变量.equals(常量)
涉及比较的场景，优先用Objects.equals(a, b)，它内部已处理双null、单null等全部情况
数据库映射字段用Integer而非int是对的，但后续业务逻辑中若需算术运算，先用Objects.nonNull()或Optional.ofNullable()兜底

最易被忽略的点：NPE从来不是孤立的bug，而是信号——它暴露了调用契约模糊、输入边界未定义、或模块间缺乏空值约定。与其在线上抓堆栈，不如在接口设计时就决定：这个方法到底返null还是空集合？这个DTO字段可空是否需要文档标注？这些决策比写十行判空代码影响更深远。