应使用 equals() 而非 == 比较集合元素，因 == 比较对象引用而非值：Integer 缓存导致 -128~127 内可能误判；浮点数精度使 0.1+0.2==0.3 为 false；自定义类未重写 equals() 时比较地址；字符串字面量在常量池而 new 出的不在。

直接用 == 比较集合中的元素，容易出错，核心原因在于它比的不是“值是否相等”，而是“是不是同一个对象”。这在集合去重、查找、判断存在性等场景下极易导致逻辑错误。

Integer包装类的缓存陷阱

Java 对 -128 到 127 范围内的 Integer 值做了缓存。用 == 比较两个在这个范围内的 Integer 变量，有时返回 true；超出范围就大概率返回 false——哪怕它们数值完全一样。

• Integer a = 100; Integer b = 100; → a == b 是 true（共享缓存对象）
• Integer c = 200; Integer d = 200; → c == d 是 false（各自新建对象）

浮点数精度导致的语义失效

double 或 float 类型本身存在二进制表示误差。两个数学上“应该相等”的计算结果，其二进制位可能略有差异。

• 0.1 + 0.2 == 0.3 在 Java 中结果为 false
• 因为 == 要求位模式完全一致，而浮点运算无法保证这点

自定义对象默认比较的是内存地址

如果集合里存的是自定义类（比如 User），而该类没重写 equals() 和 hashCode()，那么：

• set.contains(user1) 内部调用的是 user1.equals(集合中每个元素)
• 但若没重写 equals()，实际走的是 Object 的默认实现——比较引用地址
• 即使两个 User 的 id、name 完全相同，只要不是同一个实例，== 或未重写的 equals() 都会判定为不等

字符串虽是引用类型，但有特殊处理

字符串字面量会进入常量池，所以 "abc" == "abc" 为 true；但通过 new String("abc") 创建的就不是同一对象。

• 集合中若混入 new 出来的字符串，用 == 查找会失败
• 应统一使用 .equals()，它按字符内容逐位比较