Stream.collect(Collectors.toSet())去重失效的根本原因是自定义对象未重写equals()和hashCode()方法，导致HashSet无法正确识别逻辑重复；标准类型无需额外操作，而TreeSet需显式构造且性能较低。
为什么 Stream.collect(Collectors.toSet()) 有时不按预期去重？
直接用 collect(Collectors.toSet()) 确实能生成一个 Set，但它的底层默认使用 HashSet，而 HashSet 去重依赖对象的 equals() 和 hashCode()。如果流中是自定义对象（比如 User），且没重写这两个方法，哪怕字段值完全一样，也会被当成不同元素保留下来。
常见错误现象：stream.filter(...).collect(Collectors.toSet()) 返回的集合 size 比预期大，甚至包含“重复”对象。
- 检查目标类是否已正确定义
equals()和hashCode()（IDE 通常可自动生成） - 若处理的是基本类型或
String/Integer等标准类型，无需额外操作——它们的equals已正确实现 - 不要试图靠
TreeSet替代来“强行去重”，除非你真需要排序；否则会因缺少Comparable抛出ClassCastException
想用 TreeSet 保持有序且去重，该怎么写？
Collectors.toSet() 固定返回 HashSet，不支持传参指定实现类。要换成 TreeSet，必须用更底层的 Collector.of() 或显式构造。
推荐写法（简洁安全）：
Set<string> result = stream
.filter(Objects::nonNull)
.collect(TreeSet::new, TreeSet::add, TreeSet::addAll);
</string>
- 第一个参数是 supplier：
TreeSet::new - 第二个是 accumulator：
TreeSet::add，注意不是add的返回值（boolean），而是引用本身 - 第三个是 combiner：多线程并行流合并时用，单线程可简化为
(a, b) -> { a.addAll(b); }，但用方法引用更一致 - 若元素类型未实现
Comparable，需显式传入Comparator，例如new TreeSet(Comparator.comparing(User::getId))
性能差异：HashSet vs TreeSet 收集哪个更快？
绝大多数场景下，Collectors.toSet()（即 HashSet）比手动构造 TreeSet 快 2–3 倍，尤其数据量超过千条时。
-
HashSet.add()平均时间复杂度 O(1)，扩容成本低 -
TreeSet.add()是 O(log n)，每次插入都要做红黑树平衡 - 如果只是去重+后续遍历无序，别为“看起来整齐”选
TreeSet - 并行流下
HashSet的收集器天然支持分段合并，TreeSet的自定义 collector 需确保 combiner 正确，否则结果错乱
替代方案：不用 toSet()，但也要高效去重
当过滤后还需进一步操作（如取前 N 条、按条件再分组），直接收集到 Set 反而浪费——不如在流中就控制去重逻辑。
- 用
distinct()：它基于LinkedHashSet内部缓存，语义清晰，适合简单去重stream.filter(...).distinct().collect(Collectors.toList()) - 对自定义对象，
distinct()同样依赖equals/hashCode，和toSet()要求一致 - 若去重要基于某字段（如只看
id），可用Collectors.toMap()技巧：stream.collect(Collectors.toMap(User::getId, Function.identity(), (a,b)->a)).values() - 注意
toMap方式不保留原始顺序（除非用LinkedHashMap作为 map factory）
真正要注意的，不是“怎么写 collect”，而是确认你的对象有没有可靠的 equals 实现——其他所有优化都建立在这个基础上。没重写 hashCode 却只重写 equals，或者用了 Lombok 但忘了加 @EqualsAndHashCode，都会让去重彻底失效。
