java自动拆箱是npe高频源头，因拆箱实为调用xxxvalue()实例方法，null无法响应；装箱调用valueof()静态方法则安全。
Java 中自动拆箱是空指针异常（NPE）的高频源头，根本原因在于：拆箱不是类型转换，而是对包装类对象调用 xxxValue() 实例方法（如 intValue()），而 null 无法响应任何实例方法调用。装箱（调用 valueOf() 静态方法）则不会 NPE。要避免，关键是在拆箱发生前切断 null 流入基本类型上下文的路径。
识别所有隐式拆箱场景
这些写法看似安全，实则悄悄触发拆箱，一旦包装类为 null 就立刻崩溃：
-
与基本类型比较：如
Integer status = null; if (status == 1) { ... } -
参与算术运算：如
Integer count = null; int total = count + 10; -
三目运算中类型统一：如
int result = flag ? 5 : value;（value是null的Integer） -
赋值给基本类型变量：如
int age = user.getAge();（数据库字段为空返回null） -
传入只接受基本类型的参数：如
Math.max(amount, tax)（amount或tax为null）
推荐的安全取值方式
不依赖编译器“自动”行为，主动控制 null 处理逻辑：
-
显式判空后取值：用三目运算符明确默认值，例如
int safeAge = age != null ? age : 0; -
Java 9+ 推荐用
Objects.requireNonNullElse()：简洁且语义清晰，例如int value = Objects.requireNonNullElse(obj, 0).intValue(); -
用
Optional封装：适合链式处理或需表达“可选”语义的场景，例如int safeValue = Optional.ofNullable(obj).orElse(0);；注意避免.get()和将Optional用作字段或参数 -
工具类封装复用：如
NumberUtils.toInt(Integer i, int defaultValue)，统一收口判空逻辑
从源头减少 null 包装类
防御性编码不止于“兜底”，更要压缩 null 的生存空间：
-
API 返回值优先用基本类型：如返回
int而非Integer，除非需要区分“0”和“未设置” -
DTO/VO 字段慎用包装类：必须使用时，配合 Jackson 的
@JsonSetter(nulls = Nulls.SKIP)或 MyBatis 的nullValue="0"在反序列化阶段填充默认值 -
集合操作提前过滤或映射：如
list.stream().filter(Objects::nonNull).mapToInt(Integer::intValue).sum() - 启用 IDE 静态检查：在 IntelliJ IDEA 中开启 “Boxing/unboxing of primitive types” 检查项，提前发现潜在风险点
特别注意的高危写法
以下常见简写极易忽略拆箱风险，应立即替换：
-
❌
if (flag == true)→flag是Boolean，==触发拆箱；✅ 改用Objects.equals(flag, Boolean.TRUE)或直接if (Boolean.TRUE.equals(flag)) -
❌
total = amount + tax;→ 任一为null即崩；✅ 改用(amount != null ? amount : 0) + (tax != null ? tax : 0) -
❌
Objects.requireNonNull(integerObj).intValue()→ 校验发生在拆箱之后，无效；✅ 必须写成Objects.requireNonNull(integerObj, "msg").intValue()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
