Collectors.toSet()能去重是因为其底层使用HashSet，依赖equals()和hashCode()判断重复；字符串等JDK类已规范实现，自定义对象须重写二者，null需提前过滤，性能瓶颈在哈希计算与扩容。
用 Collectors.toSet() 可以让流自动去重收集元素，但默认使用 HashSet，不保证顺序且哈希计算有开销。想兼顾去重、性能和可控性，得理解底层机制并合理选型。
为什么 toSet() 能去重？
因为 Set 接口天然不允许重复元素，Collectors.toSet() 内部默认构造的是 HashSet，依赖对象的 equals() 和 hashCode() 判断是否重复。只要你的元素正确重写了这两个方法，去重就自动生效。
- 字符串、包装类（Integer、Long 等）、LocalDate 等 JDK 类已内置规范实现，可直接用
- 自定义对象必须重写
equals()和hashCode()，否则所有实例都被视为不同元素 - 若元素为
null，HashSet允许存一个null，但多次收集可能引发空指针，建议提前过滤
性能瓶颈在哪？怎么优化？
主要开销来自哈希计算、扩容和哈希冲突处理。优化方向不是“避免用 toSet”，而是“用对场景 + 换更合适的 Set 实现”：
- 小数据量（：改用
Collectors.toCollection(LinkedHashSet::new)，插入顺序保留，哈希表结构简单，比 HashSet 更轻量 -
已知元素范围小、可枚举（如状态码、枚举值）：用
EnumSet或布尔数组预判，再转流，比泛型 Set 快一个数量级 -
大量重复 + 高频调用：先用
distinct()短路去重（基于LinkedHashSet缓存），再 collect，避免重复哈希计算 -
避免无谓装箱/字符串创建：例如用
int流处理 ID，别先 map 成Integer再 toSet；字符串尽量复用 intern 或用 valueOf
替代方案对比：什么情况不该用 toSet()？
不是所有去重都适合 toSet()。以下场景建议换方式：
-
要保留首次出现顺序且后续还要遍历：
toCollection(LinkedHashSet::new)比toSet()更明确、可读性更好 -
只关心是否存在，不关心集合本身：用
anyMatch()+ 自定义缓存（如ConcurrentHashMap的 computeIfAbsent）更省内存 -
去重后立刻聚合（如计数、求和）：跳过收集成 Set 这一步，改用
collectingAndThen(toSet(), Set::size)或直接distinct().count() - 元素不可哈希（如含可变字段的类）：必须先投影成不可变键（如 id 字段），再按键去重，否则行为不可靠
一个实用的增强工具方法
封装常用模式，避免每次写冗长代码：
public static <T> Collector<T, ?, Set<T>> toLinkedSet() {
return Collectors.toCollection(LinkedHashSet::new);
}
// 使用示例
List<String> list = Arrays.asList("a", "b", "a", "c");
Set<String> set = list.stream().collect(toLinkedSet()); // [a, b, c]，顺序确定
这样既保持语义清晰，又控制了底层实现，还便于统一替换优化策略（比如将来换成并发安全的 CopyOnWriteArraySet，只需改一行）。
