contains() 方法先查 hashcode()（哈希集合）再逐个 equals()，arraylist 全遍历、hashset 定位桶后比较，自定义类须同时重写 equals() 和 hashcode() 且逻辑一致，否则查不到；null 处理因集合而异，需特别注意。
contains() 方法到底比什么
contains() 不是简单地比内存地址，也不是无脑调用 equals() 就完事——它先查 hashCode()（对哈希类集合），再逐个调用 equals()。比如 ArrayList 从头遍历，每个元素都调 equals()；而 HashSet 先算 hashCode() 定位桶，只在同一个桶里挨个 equals()。
- 如果对象没重写
equals()和hashCode()，默认用的是Object的实现，也就是比较引用（即==），这时候两个内容相同但不同实例的对象，contains()一定返回false -
String、Integer等 JDK 类已经重写好了，直接用没问题 - 自定义类必须同时重写
equals()和hashCode()，且逻辑自洽：如果equals()返回true，两个对象的hashCode()必须相等
为什么重写了 equals 却还是 contains 不到
常见现象：contains() 返回 false，但手动遍历 + equals() 却能匹配上。大概率是 hashCode() 没同步更新，或者重写有 bug。
-
HashSet/HashMap依赖hashCode()快速分流，如果hashCode()返回值不稳定（比如用了随机数、当前时间、未被final修饰的可变字段），会导致对象“掉桶”——存进去时在一个桶，查的时候算出另一个桶，根本不会走到equals()这步 - 常见错误写法：
hashCode()只基于部分字段计算，而equals()比较全部字段；或equals()里用了instanceof判类型，但子类重写后破坏了对称性 - IDE 自动生成的
equals()/hashCode()一般靠谱，但要注意字段是否全选、是否包含可变状态（比如ArrayList里的元素变了，但对象本身hashCode()没变）
contains() 在不同集合里的性能差异
同样是查一个对象，耗时可能差一个数量级，取决于底层数据结构和元素分布。
-
ArrayList：O(n)，最坏遍历全部；适合小数据量或插入频繁、查询少的场景 -
LinkedList：也是 O(n)，但每次next()是指针跳转，缓存不友好，实际比ArrayList更慢 -
HashSet：平均 O(1)，但极端情况（所有元素哈希冲突）退化成 O(n)；要求对象hashCode()分布均匀 -
TreeSet：O(log n)，靠compareTo()或Comparator排序，不要求hashCode()，但要求可比较且逻辑一致；如果误把null放进去又没处理，contains()直接抛NullPointerException
contains(null) 的行为要特别小心
null 是个特例，不同集合处理方式不统一，容易踩空指针或逻辑错乱。
立即学习“Java免费学习笔记（深入）”；
-
ArrayList、LinkedList：允许存null，contains(null)会正常遍历，用==判断，安全 -
HashSet：允许存一个null，contains(null)返回true（如果存过）；但注意HashMap的 key 为null时，get()和containsKey()行为一致，而containsValue()仍需遍历 -
TreeSet：默认不允许null，contains(null)直接抛NullPointerException；除非构造时传了显式Comparator且支持null - 所有集合的
contains()方法本身不校验参数是否为null，所以如果你传了个未判空的变量进去，出问题时堆栈未必指向你调用的地方，而是指向集合内部的equals()或compareTo()
判断是否包含某个对象这件事，表面是 API 调用，背后绑着对象契约、集合实现、甚至 JVM 对哈希表的优化策略。最容易被忽略的，不是怎么写 contains()，而是改了业务字段后忘了同步更新 hashCode() 逻辑，或者在 TreeSet 里混用了可 null 和不可 null 的对象。
