分支结构中用 == 比较包装类特别危险，因其隐含自动拆箱，-128~127外或null时抛NPE，且null来源隐蔽导致延迟崩溃；应统一用Objects.equals、显式判空或getOrDefault避免拆箱。
为什么分支结构中用 == 比较包装类特别危险
分支结构（如 if、三元运算符、switch）常隐含类型推导和自动拆箱动作，而 == 在包装类间比较时行为不一致：在 -128~127 缓存范围内可能“碰巧”相等，超出范围或遇到 null 就立即崩溃。更关键的是，分支逻辑往往让 null 的来源变得隐蔽——比如某个子路径反序列化失败、默认构造未初始化、或 Map.get() 返回 null，这些都可能只在特定条件分支中触发，导致 NPE 延迟出现、复现困难。
典型高危场景与识别特征
以下代码模式极易埋雷，需重点扫描：
-
if 条件中混用基本类型与包装类：如
if (user.getStatus() == 1)，其中 getStatus() 返回 Integer，值为 null 时直接抛 NPE -
三元运算符左右操作数类型不一致：如
Integer a = flag ? 10 : someMethodThatReturnsNull();，编译器会先对 10 拆箱再装箱，null 分支一执行就崩 -
switch 表达式作用于包装类：Java 14+ 支持 switch(Integer)，但若传入 null，运行时报
java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" - 策略类/工厂类中字段类型不统一：不同实现类对同一语义字段（如 enabled、retryCount）一个用 boolean，一个用 Boolean，分支路由后行为割裂
快速定位的实操方法
不用等线上报错，从开发阶段就能拦截：
- 在 IDE 中启用「boxing/unboxing inspection」并设为 warning 或 error，它能标出所有隐式拆箱点
- 对所有参与分支判断的包装类 getter 方法，在调用前加临时日志：
log.debug("status={}", user.getStatus())，观察是否输出 null - 用 Jacoco 或 IDEA 的行覆盖率工具跑单元测试，重点关注分支覆盖——未覆盖的 else 路径往往是 null 高发区
- 检查 JSON 反序列化配置：若用 Jackson，确认全局未开启
DeserializationFeature.ACCEPT_NULL_AS_EMPTY，否则 null 会被静默转成 0/false，掩盖问题
安全替代方案不是选“怎么比”，而是“不给机会比”
与其纠结 == 还是 equals()，不如重构逻辑，避开拆箱入口：
- 数值比较统一走
Objects.equals(a, b)，它不拆箱、不判空、不抛异常 - 布尔状态判断改用显式语义方法：
if (Boolean.TRUE.equals(user.isActive()))或封装为user.isActiveTrue() - 三元表达式强制统一类型：
Integer result = flag ? Integer.valueOf(10) : Optional.ofNullable(someMethod()).orElse(null); - Map 取值绝不裸用自动拆箱：
map.get("count") != null ? map.get("count").intValue() : 0改为map.getOrDefault("count", 0).intValue()
