HashSet判断重复先比hashCode()再比equals()，本质是用空间换时间的分层筛选策略：哈希值快速分桶定位，equals精准确认逻辑相等，二者必须同时重写并遵守契约，否则导致重复误判或查找失效。
HashSet 判断重复时先比 hashCode() 再比 equals()，本质是用空间换时间的分层筛选策略——第一层快速排除，第二层精准确认。
哈希值用于快速分桶定位
HashSet 底层基于 HashMap 实现，元素作为 key 存储。添加新元素时，先调用其 hashCode()，通过哈希算法（如 (h ^ (h >>> 16)) & (table.length - 1)）算出数组索引位置。这个过程是 O(1) 的，不依赖集合大小。
- 如果目标桶为空，直接插入，无需任何比较
- 如果桶里已有元素，才触发后续检查
- 不同对象可能哈希值相同（哈希冲突），但绝大多数情况下哈希值不同 → 直接跳过 equals 调用
equals 是冲突后的必要精筛
当两个对象 hashCode() 相同，它们被分配到同一个桶中，这时必须逐个调用 equals() 判断是否真正逻辑相等。这是唯一能保证语义正确性的手段。
- 仅靠
hashCode()不足以判定相等：例如"Aa"和"BB"的哈希值在 JDK 中恰好相同，但内容显然不同 - 只重写
equals()不重写hashCode()，会导致逻辑相等的对象被分到不同桶，equals()根本不会被调用 - 哈希冲突不可避免，但良好的
hashCode()实现能让冲突概率足够低，使平均查找成本趋近常数
两步配合带来实际性能优势
对大规模数据集，这种设计显著减少 equals() 的调用次数——而 equals() 往往涉及字段逐个比较，开销远高于整数哈希值计算。
立即学习“Java免费学习笔记（深入）”；
- 假设集合有 10000 个元素，哈希分布均匀时，单个桶平均只有几个元素；每次插入最多比较几次 equals，而非遍历全部
- 基本类型（如 Integer、String）的
hashCode()高效稳定，使得 HashSet 对这些类型几乎始终维持 O(1) 插入/查询 - 自定义类若未合理重写二者，性能和正确性都会受损：要么大量误判（只看哈希），要么退化为线性扫描（哈希全撞一起）
违反契约会破坏整个机制
hashCode() 和 equals() 必须遵守 Java 规范的契约，否则分层逻辑失效：
- 若
a.equals(b)为 true，但a.hashCode() != b.hashCode()→ 二者进不同桶，equals()永不触发，重复元素被错误接受 - 若
hashCode()依赖可变字段（如修改 name 后哈希值变），对象加入 HashSet 后再修改，会导致后续contains()找不到自己 - 推荐统一用
Objects.hash(f1, f2, ...)和Objects.equals(a, b)，天然处理 null，降低出错概率
