根治自动装箱/拆箱隐患需从代码写法、数据来源、编译逻辑三处主动设防，紧盯包装类型在运算、比较、三目表达式中的隐式拆箱，严控数据库NULL、远程调用空值等数据入口，并借助静态检查工具与编码规范双保险。
排查和根治自动装箱/拆箱隐患，关键不是等报错再修，而是从代码写法、数据来源、编译逻辑三处主动设防。最危险的空指针往往不发生在显式调用 intValue() 的地方，而藏在看似安全的加减运算、三目表达式或缓存取值中。
盯紧所有参与运算和比较的包装类型变量
只要 Integer、Long、Boolean 出现在 +、-、*、/、==（与基本类型比）、if (obj > 0) 这类上下文中，就一定触发拆箱——哪怕你没写 .intValue()。
- 检查数据库映射字段：若 MyBatis 或 JPA 实体中用了
Integer status，但数据库该列允许 NULL，那任何对status + 1或status == 1的使用都可能炸 - 扫描 RPC/HTTP 接口 DTO：远程返回的
Long amount若未传值，JSON 解析后为 null，后续直接用于计算就会 NPE - 禁用“隐式数值比较”：把
if (user.getAge() > 18)改成Objects.nonNull(user.getAge()) && user.getAge() > 18
重审三目运算和默认值赋值逻辑
三目运算符是隐形装箱高发区。一边是基本类型字面量（如 0），一边是包装类变量（如 dbValue），编译器会强制统一为包装类型，导致整个表达式结果可为 null，后续再拆箱就崩。
- 错误写法：
int result = flag ? 1 : dbCount;（dbCount为Integer，null 时拆箱失败） - 正确写法：
int result = flag ? 1 : Objects.requireNonNullElse(dbCount, 0);或更稳妥地先判空：int result = dbCount != null ? (flag ? 1 : dbCount) : 0; - DTO 构建时避免混用：
order.setTotalAmount(params.getAmount() != null ? params.getAmount() : BigDecimal.ZERO)比params.getAmount() ?: BigDecimal.ZERO（Kotlin 风格）更可控
统一治理数据入口与缓存层
空值最常来自外部：数据库 NULL、Redis 未命中、Feign 调用超时返回 null、MQ 消息字段缺失。这些地方不做兜底，后面所有业务逻辑都是沙上筑塔。
立即学习“Java免费学习笔记（深入）”；
- DAO 层加注解约束：MyBatis-Plus 可配
@TableField(fill = FieldFill.INSERT)或用@TableLogic避免 NULL 状态字段 - 缓存读取强制非空转换：
Long cacheVal = redisTemplate.opsForValue().get(key); return cacheVal != null ? cacheVal : 0L;，绝不写long val = redisTemplate.opsForValue().get(key); - RPC 客户端封装 null 安全调用：
Long amount = Optional.ofNullable(paymentService.queryAmount(id)).orElse(0L);
用工具和规范提前拦截
单靠人眼 review 很难覆盖全部边界。要靠静态检查+编码规范双保险。
- 启用 SpotBugs 或 Alibaba Java Coding Guidelines 插件，开启
NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE和BC_UNCONFIRMED_CAST类规则 - 在 CI 流程中加入 NullAway 编译期检查，它能精准识别哪些包装类型变量可能为 null 并参与了拆箱
- 团队约定：所有对外接收的数值型字段（DTO、VO、Entity）必须显式处理 null；内部计算一律优先用基本类型局部变量承接，如
int realStatus = obj.getStatus() != null ? obj.getStatus() : 0;
