排查 NullPointerException 的关键是识别包装类型隐式拆箱：Integer、Long 等转为基本类型时遇 null 即崩；需追溯调用链定位空值来源，检查方法返回、集合取值、三方接口等场景，并用 Objects.equals、显式判空、注解校验等方式预防。
排查这类 NullPointerException，核心是抓住“包装类型转基本类型时隐式拆箱”这一关键路径。只要涉及 Integer、Long、Boolean 等包装类变量直接赋值给 int、long、boolean 等基本类型，或参与算术、比较（如 ==）、逻辑运算，就极可能触发自动拆箱——而 null 值一拆即崩。
定位空值来源：从调用链向上追溯
异常堆栈通常只显示崩溃行（如 int id = user.getId();），但真正的问题在上游。重点检查：
- 方法返回值是否声明为包装类型（如
public Integer getId()），但实际实现中可能返回null（数据库查无记录、DTO未赋值、JSON反序列化缺失字段） - 集合取值操作，如
list.get(0)或map.get("key")返回包装类型却未判空 - 三方接口或 RPC 响应对象中的包装字段，尤其在兼容旧版协议时容易留空
识别高危写法：一眼看出哪些代码会拆箱
以下写法均会触发自动拆箱，若左侧变量为 null，必抛 NPE：
-
int age = user.getAge();（赋值） -
if (user.getAge() == 18)（== 比较，左边 Integer 自动拆箱） -
total += order.getAmount();（算术运算，Amount 是 BigDecimal 或 Long） -
return status.getCode() + "";（字符串拼接，getCode() 返回 Integer）
快速验证与修复：用工具和约定降低风险
不依赖肉眼排查，用更可靠的方式守住底线：
- 启用编译器警告：IDE 中开启
Unboxing of a null value类型的 inspection（IntelliJ/VS Code Java 插件均支持） - 用
Objects.equals(a, b)替代==比较包装类型与基本类型（如Objects.equals(user.getStatus(), 1)） - 对明确可能为 null 的包装字段，统一用
xxx != null ? xxx : defaultValue显式处理，避免依赖自动转换 - 在 DTO、Entity 层加 Lombok
@Getter(onMethod_ = @NonNull)或使用@NotNull注解配合 Hibernate Validator，在入参校验阶段拦截
预防性设计：从源头减少 null 包装类型
与其反复救火，不如限制 null 的传播范围：
- 数据库映射字段若业务上不允许为空，JPA 中用
@Column(nullable = false)，MyBatis 中配置jdbcType=INTEGER并设默认值 - 构造对象时优先使用 builder 模式或全参构造，避免部分字段遗漏导致包装类型为 null
- 对外提供 API 时，将包装类型字段改为基本类型 + 默认值（如
int age = 0），并在文档中说明 0 表示“未知”而非“年龄为 0”
