关键是从写法、设计和工具三方面提前拦截：明确==比较、算术运算、三目混用、基本类型方法调用等会触发隐式拆箱；采用显式判空、Objects.requireNonNullElse、Optional或默认值配置；源头减少null包装类，辅以IDE检查与单元测试。
直接避免包装类自动拆箱引发空指针异常，关键不是“等它出错再捕获”，而是从写法、设计和工具三方面提前拦截——null 值在拆箱那一刻才爆炸，但隐患早在赋值、返回、反序列化时就埋下了。
明确哪些操作会触发隐式拆箱
这些看似安全的写法，其实都在悄悄调用 xxxValue() 方法，一旦对象为 null 就立即抛 NullPointerException：
-
基本类型与包装类用 == 或 != 比较：如
Integer a = null; if (a == 0) -
参与算术或逻辑运算：如
Integer x = null; int y = x + 1;或Boolean flag = null; if (flag && condition) -
三目运算中混用基本类型与包装类：如
int result = cond ? 1 : integerVal;（当integerVal为null时，JLS 要求统一为int类型，强制拆箱） -
传入只接受基本类型参数的方法：如
Math.max(5, nullableInt)、Arrays.sort(intArray)中误传Integer[]
用安全写法替代隐式拆箱
不依赖 JVM 的自动行为，主动控制 null 处理路径：
-
显式判空取值：
int value = (obj != null) ? obj.intValue() : 0; -
用
Objects.requireNonNullElse()（Java 9+）：int value = Objects.requireNonNullElse(obj, 0).intValue(); -
用
Optional表达可选语义：int value = Optional.ofNullable(obj).orElse(0);（更清晰表达“可能不存在”意图） -
数据库/JSON 场景设默认值：MyBatis 中配置
nullValue="0"；Jackson 反序列化时用@JsonSetter(nulls = Nulls.SKIP)或全局DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES关闭自动失败
从源头减少 null 包装类出现
预防比修复更高效：
立即学习“Java免费学习笔记（深入）”；
-
方法返回值优先用基本类型：除非需要区分“0”和“未设置”，否则不要返回
Integer，直接返回int -
DTO/VO 字段慎用包装类：若字段必填，用
int+@NotNull配合校验；若允许缺失，用Optional<integer></integer>或明确注释语义 -
集合存原始类型：避免
List<integer></integer>，改用IntList（Eclipse Collections）、IntArrayList（FastUtil）等原始集合库，彻底绕过装箱/拆箱 -
工具类封装通用逻辑：如
NumberUtils.toInt(Integer i, int default)，把判空逻辑收口，避免散落各处
借助工具提前发现隐患
人会疏忽，工具不会：
-
IDE 静态检查：IntelliJ IDEA 开启
Boxing/unboxing of primitive types相关 inspection，能标出潜在拆箱 NPE -
Lombok 辅助但不替代：
@NonNull可提醒入参不应为 null，但运行时仍需配合判空；@SneakyThrows不解决根本问题，反而掩盖风险 -
单元测试覆盖边界：对所有接收包装类参数的方法，显式传
null测试是否崩溃，尤其关注三目运算、mapToInt、Stream 聚合等高频陷阱点
