应优先用 HashSet 去重，因其平均时间复杂度 O(1)，远优于 ArrayList 的 O(n²)；但需确保元素正确重写 equals() 和 hashCode()，自定义对象否则无法去重；若需保序用 LinkedHashSet，按字段去重推荐 Collectors.toMap()。
为什么用 HashSet 而不是 ArrayList 去重
直接用 ArrayList 手动遍历去重，时间复杂度是 O(n²)，数据一过万就明显卡顿；HashSet 底层基于哈希表，插入和查重都是平均 O(1)，适合大多数去重场景。但要注意：元素必须正确重写 equals() 和 hashCode()，否则自定义对象会重复添加。
常见错误现象：HashSet 里出现“看起来一样”的对象却没去重——大概率是忘了重写 hashCode()，或者只重写了 equals()。
- 字符串、Integer 等 JDK 内置类型已默认实现，可直接用
- 自定义类（如
User）必须同时重写equals()和hashCode() - 若需保持插入顺序，改用
LinkedHashSet，性能略低但顺序可靠
Stream.distinct() 的适用边界在哪里
Stream.distinct() 看起来简洁，但它依赖元素的 equals() 判断，和 HashSet 底层逻辑一致。优势是链式调用方便，劣势是无法控制去重逻辑（比如按某个字段去重），且对大集合存在额外装箱/流开销。
典型使用场景：对简单类型或已规范重写 equals() 的对象做全量去重。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 基础类型数组转流去重：
Arrays.stream(arr).distinct().toArray() - 不适用于按某字段（如
user.getId()）去重——得用Collectors.toMap()或Collectors.collectingAndThen() - 原始类型流（
IntStream）不支持distinct()直接去重，需先 boxed
按单个字段去重时别硬套 HashSet
想保留“相同 userId 只留第一个”，但又不想改对象的 equals() 逻辑？这时候强行让 HashSet 存 userId 字符串再过滤原列表，代码易错且难维护。
更稳妥的做法是用 Collectors.toMap() + Function.identity()：
List<User> uniqueByUserId = users.stream()
.collect(Collectors.toMap(
User::getUserId,
Function.identity(),
(u1, u2) -> u1 // 冲突时保留第一个
))
.values()
.stream()
.collect(Collectors.toList());
- 注意第三个参数是冲突解决策略，
(u1, u2) -> u1表示取先遇到的 - 如果字段可能为
null，toMap()会抛NullPointerException，需提前过滤或用Collectors.groupingBy()替代 - 该方式天然支持多字段组合去重（如
u -> u.getUserId() + "-" + u.getType()）
大数据量下 TreeSet 不是“更稳”的选择
有人觉得 TreeSet 按自然序去重“更可控”，但实际它用红黑树实现，插入是 O(log n)，比 HashSet 慢 3–5 倍；而且要求元素实现 Comparable 或传入 Comparator，稍不注意就抛 ClassCastException。
除非你明确需要排序结果+去重一步到位，否则不要为了“看起来严谨”选 TreeSet。
- 去重后还要排序？先用
HashSet去重，再单独Collections.sort() - 自定义比较逻辑复杂时，
TreeSet的Comparator容易写错边界（比如漏处理null） - 并发场景下三者都不安全，得换
ConcurrentHashMap配合逻辑，或用CopyOnWriteArraySet（仅小集合）
HashSet 就够了；难点往往不在“怎么去”，而在“按什么去”——字段是否为空、是否要保序、是否要保留最新/最旧的一条，这些业务逻辑一旦模糊，再花哨的集合也救不了。 
