关键在识别哪一层悄悄拆箱，而非定位报错行；三元运算、stream.collect、算术表达式及方法赋值时易因包装类null触发隐式拆箱npe，需统一用optional、objects工具或注解防控。
排查多层分支嵌套中因基本类型异常码与包装类隐式转换引发的空指针，关键不在“找哪一行报错”，而在“识别哪一层悄悄拆了箱”。这类问题往往不抛在你写的 if 判断里，而发生在三元运算、Stream.collect、算术表达式或方法返回值赋值的瞬间。
盯紧三元运算符的类型统一过程
当分支一边是 0（int 字面量），另一边是 Integer errorCode（可能为 null），JVM 会强制将整个表达式推断为 int 类型，进而对 null 的 Integer 执行 intValue() —— 此时还没进业务逻辑，NPE 已经抛出。
- 错误写法：
int code = flag ? 0 : response.getErrorCode();（response.getErrorCode() 返回 Integer） - 安全写法：
Integer code = flag ? 0 : response.getErrorCode();或int code = flag ? 0 : Objects.requireNonNullElse(response.getErrorCode(), 0);
检查 Stream 链式操作中的 toMap / groupingBy
Collectors.toMap 的 value mapper 若返回包装类（如 Integer），而实际值为 null，就会在 merge 阶段触发 NPE；同理，groupingBy 若 key mapper 返回 null，也会立即失败。
- 典型风险点：
.collect(Collectors.toMap(User::getName, User::getAge))—— getAge() 返回 Integer，null 值直接崩 - 稳妥做法：显式处理 null 值，例如用
t -> Optional.ofNullable(t.getAge()).orElse(0)，或改用Collectors.collectingAndThen(..., map -> ...)后置校验
扫描所有自动拆箱发生的位置
只要出现 包装类参与算术、比较、逻辑运算或作为 switch 表达式 case 值，就存在隐式拆箱风险。多层嵌套会让这个动作藏得更深。
- 常见陷阱位置：if 条件里的
count != null && count > 0（count 是 Integer，>触发拆箱） - 远程调用后链式处理：
rpcResult.getCode().equals(200)—— getCode() 返回 Integer，.equals() 不拆箱，但若写成rpcResult.getCode() == 200就会拆箱崩溃 - 修复思路：统一用 Objects.equals(a, b) 替代 == 比较包装类；用 Optional.ofNullable(x).orElse(0) 替代 x == null ? 0 : x
启用编译期空值检查并标注契约
靠肉眼扫代码效率低且易漏。用 @Nullable / @NonNull 注解配合 IDE（如 IntelliJ）的空值分析，能让大部分隐式拆箱风险在编码阶段标红提示。
- 在方法签名中标明：
public @NotNull Integer getErrorCode() { ... }或public @Nullable Integer getErrorCode() { ... } - 对入参加
@NonNull，让 Lombok 的 @RequiredArgsConstructor 或 Spring 的 @Valid 自动拦截 null 传入 - 避免在 DTO、VO 中混用 int 和 Integer —— 统一选一种，并在团队规范中明确：异常码字段一律用 Integer + 显式判空，或用枚举替代魔法数字
