应使用 objects.equals(a, b) 替代包装类的 == 比较，因其可安全处理 null 且避免缓存机制导致的逻辑穿透；需重点排查分支条件、三元运算符及 switch 中的包装类 == 表达式，并通过哈希码与类型日志验证对象实例一致性。
排查分支中因包装类对象误用 == 导致的逻辑穿透，关键在于识别“本该走 A 分支却走了 B 分支”这类行为异常，而非仅看编译或运行时错误。这类问题隐蔽性强，常在值落在缓存边界（如 127/128）附近或跨类型比较时暴露。
定位可疑 == 比较点
在分支条件中搜索所有涉及包装类（Integer、Long、Byte、Short、Character、Boolean）的 == 表达式，尤其关注：
- if 条件里直接写
if (obj1 == obj2)，且二者均为非基本类型变量 - 三元运算符中使用
?:判断，如result = (a == b) ? "yes" : "no" - switch 表达式（Java 14+）中用包装类作 case 值，但实际比较仍依赖 == 语义
验证是否触发缓存机制
对每个疑似点，检查参与比较的两个操作数是否都来自自动装箱（如 Integer a = 100），还是其中一方为 new Integer(100) 或来自 JSON/DB 反序列化（通常绕过缓存）。可加日志辅助判断：
- 打印对象哈希码：
System.out.println(System.identityHashCode(a) + " vs " + System.identityHashCode(b)); - 打印类名与值：
System.out.println(a.getClass() + "@" + a + " == " + b.getClass() + "@" + b); - 若哈希码相同，说明是同一对象（缓存命中）；不同则说明是不同实例，此时
==必为false，即使数值相等
复现边界值场景
缓存默认范围是 -128 到 127（Integer 等），因此需重点测试：
- 值为 127：自动装箱的两个变量
==很可能为true - 值为 128：同样写法，
==极大概率变为false，导致分支跳转突变 - 混合类型比较：如
Integer i = 100; Long l = 100L; if (i == l)→ 实际触发拆箱为int == long，虽结果正确但语义混乱，且在i = null时会抛NullPointerException
统一修复与防护
不依赖缓存行为，改用稳定语义：
- 同类型比较：一律改用
.equals()，例如if (a != null && a.equals(b)) - 更安全写法：使用
Objects.equals(a, b)，自动处理null，无需判空 - 明确需要引用相等的极少数场景（如单例校验），应加注释说明，并确保双方来源可控（如都来自
Boolean.TRUE） - CI 阶段加入静态检查规则（如 SonarQube 规则
S2177或自定义 PMD 规则），禁止包装类间直接使用==
