自动拆箱会触发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");</string> → 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)

工具类和工程化防护

避免每个地方重复写三元判断，可沉淀为可复用方案：

• 自定义工具方法：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，并在反序列化阶段配置默认值

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南