contains返回false因默认用Object.equals比内存地址，需重写equals（并同步重写hashCode）才能按值比较；String等已重写故正常，自定义类必须手动实现。
为什么 contains 有时返回 false，明明对象“看起来一样”？
因为 contains 默认靠 equals 判断相等，而没重写 equals 的类（比如自定义类）用的是 Object.equals —— 它只比内存地址。两个字段值完全相同的对象，只要不是同一个实例，contains 就查不到。
常见错误现象：
• 新建一个和 List 里“长得一样”的对象去调 list.contains(new User("zhang", 25))，结果是 false
• 调试发现 List 里确实有 User("zhang", 25)，但就是不匹配
- 必须重写
equals（同时强烈建议重写hashCode，否则放进HashSet/HashMap会出问题） - 重写时只比较业务上认定“相同”的字段，比如
id或username，别无脑比所有字段 - 注意
null安全：用Objects.equals(a, b)替代a.equals(b)，避免 NPE
contains 查的是值还是引用？和 == 有什么区别？
contains 走的是逻辑相等（equals），不是引用相等（==）。对 String、Integer 等包装类，它们已重写 equals，所以能正常按值判断；但你自己的类不行。
使用场景：
• 检查用户是否已存在（按 userId 判定）
• 去重前确认某元素是否已在集合中
• 权限校验时看角色列表是否含指定 Role
立即学习“Java免费学习笔记（深入）”；
-
==比的是堆地址，contains比的是equals结果（可被重写） - 即使重写了
equals，也不要依赖==来模拟contains行为——语义完全不同 - 数组、基本类型包装类、
String这些“内置可比较类型”是例外，它们的equals已就绪
重写 equals 必须连带改 hashCode 吗？
必须。虽然 contains 本身不直接调 hashCode，但如果你这个类将来进了 HashSet 或作为 HashMap 的 key，而 hashCode 没同步更新，就会导致“能存进去却取不出来”——因为哈希桶位置错了，contains 根本不会去那个桶里调 equals。
参数差异：
• equals(Object obj) 参数类型固定，不能改签名
• hashCode() 无参，返回 int，别写成 int hashCode()（少个 @Override 注解也容易漏）
- 用 IDE 自动生成（如 IntelliJ 的
Alt+Insert → equals and hashCode），别手写 - 确保
equals和hashCode用的字段完全一致 - 如果字段可能为
null，用Objects.hash(field1, field2)，它内部会安全处理null
用 stream().anyMatch() 替代 contains 适合什么情况？
当你没法或不方便重写 equals（比如第三方类、临时对象、字段组合逻辑复杂），或者判断条件根本不是“完全相等”，而是“满足某个规则”，这时 anyMatch 更灵活。
性能影响：
• contains 是 O(n)，anyMatch 也是 O(n)，没有本质差别
• 但 anyMatch 避免了构造完整对象，有时更轻量
- 示例：查 List
中是否有年龄 > 30 且状态为 "ACTIVE" 的用户 → 只能用 anyMatch(u -> u.getAge() > 30 && "ACTIVE".equals(u.getStatus())) - 不要为了“看起来函数式”而强行替换：如果只是查 ID 相等，重写
equals+contains更清晰、复用性更强 - 注意闭包变量捕获：lambda 里用的外部变量要是
final或事实不变（effectively final）
equals 和 hashCode 是个精细活，字段选多选少、null 处理、继承关系里的 super.equals 调用，稍不注意就会埋下隐性 bug。最常被忽略的是：改了业务字段却忘了同步更新这两个方法。 
