自动拆箱会触发NPE，因其本质是调用包装类的xxxValue()实例方法，而null对象无法调用任何实例方法；装箱调用valueOf()静态方法，不依赖实例，故无NPE风险。
Java 中包装类空指针异常（NPE）最常发生在自动拆箱时——比如把 Integer、Boolean、Long 等为 null 的变量直接赋值给基本类型，或参与运算、比较、条件判断。这不是“运气不好”，而是 JVM 在底层调用 xxxValue() 方法（如 intValue()）时，对 null 执行了实例方法调用，必然失败。
明确哪些操作会触发隐式拆箱
以下写法看似简洁，但只要包装类变量为 null，运行就崩溃：
-
Integer a = null; int b = a;→ 调用a.intValue() -
Integer x = null; int y = x + 1;→x先拆箱再加法 -
Boolean flag = null; if (flag) { }→ 调用flag.booleanValue() -
Map<String, Integer> map = new HashMap<>(); int v = map.get("k");→get返回null，赋值时自动拆箱 -
Integer a = null, b = 5; Math.max(a, b);→Math.max(int, int)强制拆箱a
推荐的防御性写法
不依赖“它大概不会是 null”，而是在关键节点主动拦截：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 显式判空后取值：
int value = (num != null) ? num : 0; - 用
Objects.requireNonNullElse()（Java 9+）：int value = Objects.requireNonNullElse(num, 0).intValue(); - 用
Optional封装逻辑：int value = Optional.ofNullable(num).orElse(0); - 数据库/JSON 反序列化时统一设默认值：MyBatis 中配置
nullValue="0"；Jackson 中用@JsonSetter(nulls = Nulls.SKIP)或@JsonInclude(NON_NULL)
工具类和工程化防护
避免每个地方重复写三元判断，可沉淀为可复用方案：
立即学习“Java免费学习笔记（深入）”；
- 自定义工具方法：
NumberUtils.toInt(Integer i, int defaultValue)，内部做判空处理 - Lombok 的
@NonNull可在编译期提醒入参非空，但不解决运行时拆箱问题；配合@SneakyThrows掩盖 NPE 是反模式 - IDE 静态检查要开启：“Boxing/unboxing of primitive types” 相关 inspection，IntelliJ 和 Eclipse 均支持提前标红高危代码
从设计源头减少 null 包装类
最省心的方式，是让 null 尽量不出现在包装类变量里：
- 方法返回值优先用基本类型（如
int而非Integer），除非语义上需区分“0”和“未设置” - 集合存数字时，改用原始类型集合库（如 FastUtil 的
IntArrayList、Eclipse Collections 的IntList） - DTO/VO 字段慎用包装类；必须用时，结合
@NotNull注解 + Bean Validation，并在反序列化阶段配置默认值
