java中包装类比较应避免==（因引用比较、null异常、缓存陷阱），优先用objects.equals()；基本类型与包装类混合比较会触发危险拆箱；设计时应根据是否需null语义选择类型。
Java 中基本类型与包装类在对象比较时，最核心的问题不是“怎么比”，而是“不该用什么方式比”。关键陷阱集中在 == 运算符误用、null 导致的自动拆箱异常、缓存机制引发的偶然性结果 这三类。避开它们，比记住规则更重要。
别用 == 比较两个包装类
== 对包装类比较的是引用地址，不是数值大小：
- Integer a = 100, b = 100; a == b → true（因为 -128 ~ 127 在缓存池内，复用同一对象）
- Integer c = 200, d = 200; c == d → false（超出缓存范围，创建了两个不同对象）
- new Integer(100) == Integer.valueOf(100) → false（构造器绕过缓存，地址必然不同）
这种结果不稳定，完全依赖内部缓存策略，不能作为逻辑判断依据。
用 Objects.equals() 替代直接调用 equals()
包装类的 equals() 方法本身是正确的值比较方式，但直接调用有 null 风险：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- obj1.equals(obj2)：若 obj1 为 null，抛出 NullPointerException
- Objects.equals(a, b)：内部已处理所有 null 组合 —— null == null 返回 true，null == 非 null 返回 false，非 null 时才调用 a.equals(b)
这是 JDK 提供的标准安全写法，无需额外判空，推荐无条件使用。
避免基本类型与包装类混合比较
int a = 5; Integer b = null; if (a == b) {...} 看似合理，实则危险：
- 该表达式会触发自动拆箱：b.intValue()，而 b 是 null → 直接抛出 NullPointerException
- Float、Double、Boolean 等所有包装类都存在同样问题
- 只有「包装类 == 包装类」或「基本类型 == 基本类型」是安全的；混合比较必须先确保包装类非 null，或统一转为包装类再用 Objects.equals()
设计阶段就决定用基本类型还是包装类
是否允许 null，决定了类型选型：
- 计数器、索引、循环变量等确定不为空的场景，优先用 int/long —— 更快、更安全、无 NPE 风险
- 数据库字段映射、JSON 反序列化、集合存储等需要表达“缺失”语义的场景，才用 Integer/Long
- 一旦用了包装类，所有比较和运算前，都要考虑 null 处理路径，不要依赖自动拆箱
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
