Stream.collect(Collectors.toSet()) 不保证顺序且可能出错，因其底层为HashSet，不维护插入顺序，且在equals/hashCode不一致、对象可变或含null时可能导致去重失败或NPE。
为什么 Stream.collect(Collectors.toSet()) 不保证顺序且可能出错
Java 的 Collectors.toSet() 底层用的是 HashSet，它不维护插入顺序，也不保证线程安全。更关键的是：它**不保证去重逻辑的稳定性**——如果元素重写了 equals() 但没同步改 hashCode()，或对象本身可变（比如字段在流处理中被修改），toSet() 可能漏掉本该去重的项，甚至抛 NullPointerException（当流中含 null 时，HashSet 允许但某些场景下会触发异常）。
- 实际场景中，常见于对 DTO 或自定义对象流调用
collect(toSet())后发现大小不对、元素重复 - 若需有序去重，不能依赖
toSet()，得换容器或预排序 - 流中含
null时，toSet()虽通常能跑通，但后续操作（如stream().map(...)）容易 NPE，建议提前过滤
如何安全地用 TreeSet 实现有序去重
当需要结果按自然顺序或自定义顺序排列，同时去重，直接用 TreeSet 更可控。它基于红黑树，天然去重 + 排序，且对 null 更敏感（明确抛 NullPointerException），反而帮你早发现问题。
- 写法：
stream.collect(Collectors.toCollection(TreeSet::new)) - 若元素无自然序（如自定义类），必须传比较器：
stream.collect(Collectors.toCollection(() -> new TreeSet(Comparator.comparing(MyObj::getId)))) - 注意：
TreeSet的add()时间复杂度是 O(log n)，比HashSet的 O(1) 稍慢，大数据量时需权衡 - 不适用于含
null元素的流，哪怕只一个null都会立即失败
LinkedHashSet 是最接近“直觉预期”的去重方案
多数人想要的其实是“按首次出现顺序去重”，即保留原始流中元素的遍历顺序。这时 LinkedHashSet 是最佳选择：它既去重，又保持插入序，且性能接近 HashSet。
- 写法：
stream.collect(Collectors.toCollection(LinkedHashSet::new)) - 支持
null（仅允许一个），比TreeSet更宽容 - 若流来自数据库查询或文件读取，顺序往往有意义，用这个能避免“结果乱序”带来的调试困惑
- 注意：不要和
Collectors.toList().stream().distinct()混用——后者是中间操作，效率更低，且distinct()依赖hashCode/equals正确性，问题更隐蔽
自定义去重逻辑时，别绕开 Collectors.collectingAndThen
当标准集合不够用（比如要去重但保留某个字段值最大的那个对象），硬写循环不如用 collectingAndThen 组合收集器。它允许你在基础收集后加一层转换，干净且可复用。
- 例如：按
name去重，保留score最高的Student：stream.collect(Collectors.collectingAndThen( Collectors.toMap(Student::getName, Function.identity(), (a, b) -> a.getScore() > b.getScore() ? a : b), map -> new LinkedHashSet<>(map.values()) )) - 关键点：
toMap的 merge 函数决定了“谁留下”，最后转成LinkedHashSet保证顺序 - 避免在
map或filter中做状态变更——流是声明式，副作用易引发并发或顺序错误
LinkedHashSet::new 覆盖了最多日常场景；一旦开始纠结顺序或合并规则，就得跳出 toSet() 的舒适区，直面收集器组合的细节。 
