如何通过List.contains()方法判断特定对象是否存在于集合中？

本文共计978个文字，预计阅读时间需要4分钟。

根本原因不是方法本身存在问题，而是它依赖于+equals+判断相等性。如果元素类没有重写+equals+（以及搭配的+hashCode+），默认使用的是+Object.equals+。这也意味着比较的是引用地址而非内容。因此，即使两个对象内容相同，但不是同一个实例，也会被判断为不相等。

常见错误现象：list.contains(new Person("Alice", 25)) 返回 false，哪怕列表里已有另一个 Person("Alice", 25) 实例。

• 必须确保目标类重写了 equals()（且逻辑符合业务含义，比如按 ID 或关键字段比较）
• hashCode() 也得一并重写，否则放进 HashSet 等集合时可能出问题（虽然 List.contains() 不直接依赖它，但保持契约一致是底线）
• 使用 Lombok 的话，加 @EqualsAndHashCode 注解最省事；手写注意 null 安全和字段顺序

用 contains() 查基本类型或 String 没问题，但要注意包装类缓存

Integer、String、Boolean 这些 JDK 自带类都已正确实现 equals()，可直接用 contains()。但有个隐藏细节：小整数（-128 到 127）的 Integer 实例被缓存，所以 list.contains(42) 和 list.contains(Integer.valueOf(42)) 都能命中；而 list.contains(new Integer(42)) 也能命中（因为 equals() 比较值，不是引用）。

• 安全写法始终用自动装箱值或 valueOf()，避免 new Integer()
• String 同理：用字面量或 String.valueOf()，别用 new String("x") 做参数（虽不影响结果，但没必要）
• 浮点数慎用 contains()，Double 的 equals() 对 NaN 和精度敏感，建议用 Math.abs(a - b) 手动判断

性能陷阱：ArrayList vs LinkedList 的 contains() 效率差十倍

ArrayList.contains() 是 O(n) 遍历，但局部性好、CPU 缓存友好；LinkedList.contains() 也是 O(n)，但每次访问节点都要跳指针，实际慢得多——尤其数据量大时，差距明显。

• 如果频繁调用 contains()，优先选 ArrayList，或改用 HashSet（O(1) 平均查找）
• 若必须用 LinkedList（比如大量中间插入/删除），且又需要快速查存在性，就额外维护一个 HashSet 同步增删
• 别为了“看起来更合适”而选 LinkedList —— 大多数场景 ArrayList 更快

替代方案：什么时候不该用 List.contains()

当需求不只是“是否存在”，而是“存在哪个位置”或“出现几次”，或者要结合其他条件过滤，硬套 contains() 反而绕路。

• 要索引：用 list.indexOf(obj)，返回 -1 表示不存在
• 要计数：用 list.stream().filter(x -> x.equals(obj)).count()，或循环手动计
• 要自定义匹配逻辑（比如忽略大小写、模糊匹配）：别依赖 contains()，直接 stream().anyMatch() 或传统 for 循环
• 集合很大且只查一次？考虑是否真需要 List —— 改成 Set 结构更直白

最常被忽略的一点：contains() 的语义是“完全相等”，但业务里经常要的是“满足某条件”。这时候强行塞进 equals() 会让类职责混乱，不如用流式操作或显式遍历。