Java中List的contains()方法依赖对象类正确重写equals()（及hashCode()），否则默认用==比较地址；JDK包装类和String已重写，自定义类需手动实现并遵守契约。
Java中判断List是否包含某对象，核心是调用list.contains(obj)方法，但结果是否符合预期，取决于该对象所在类是否正确重写了equals()（以及惯例上也应重写hashCode()）。
contains底层调用的是equals，不是==
ArrayList、LinkedList等常见List实现的contains()方法，内部是遍历元素并逐个调用obj.equals(element)进行比较。它**不会**用==判断引用相等，除非你传入的元素类型没重写equals()（比如原始包装类或String已重写，但自定义类常被忽略）。
- 如果对象类没重写
equals()，则默认使用Object.equals()——本质就是==
，只比内存地址 - 例如两个
new Person("张三", 25)，即使字段完全一样，若Person未重写equals()，list.contains(p2)会返回false - String、Integer等JDK类已正确重写，所以
list.contains("abc")能按值匹配
，只比内存地址自定义类必须重写equals（和hashCode）
要让contains()按业务逻辑“相等”来判断，必须在自定义类中重写equals()方法，并确保满足对称性、传递性、一致性等契约。同时，为保持集合行为一致（尤其后续可能放入HashSet/HashMap），强烈建议一并重写hashCode()。
- IDE（如IntelliJ）可自动生成：右键 → Generate → equals() and hashCode() → 勾选参与比较的字段
- 关键点：比较前先用
instanceof检查类型，再强转；非null字段用Objects.equals(a, b)安全比较 - 错误示例：
if (this.name == other.name && this.age == other.age)—— 字符串比较用了==，且没判空
注意null值和泛型擦除的影响
contains(null)是合法的，List允许存null，只要元素中有null，就返回true。另外，泛型在运行时已擦除，contains()不校验类型，传入任意类型对象都不会编译报错（但可能永远返回false）。
- 例如
List，调用list = Arrays.asList("a", "b"); list.contains(new Integer(1))不会报错，但一定返回false（因为"a".equals(1)为false） - 这种类型不匹配通常源于逻辑错误，建议配合IDE警告或静态检查工具（如ErrorProne）提前发现
- 若需类型安全判断，可先用
stream().anyMatch()加显式类型检查，但一般没必要
性能提示：不同List实现差异大
虽然语义一致，但不同List的contains()时间复杂度不同，影响实际性能：
-
ArrayList：O(n)，顺序扫描，适合读多写少、数据量不大场景 -
LinkedList：也是O(n)，但因节点分散，缓存不友好，通常比ArrayList慢 - 若频繁查存在性，应考虑改用
HashSet（O(1)平均），前提是元素可哈希且无需维持插入顺序 - 若需有序+快速查找，可用
TreeSet（O(log n)），但要求元素可比较或提供Comparator
基本上就这些。记住核心：contains靠equals说话，equals靠你写对——不复杂但容易忽略。
