HashSet去重失败的根本原因是对象未正确重写equals()和hashCode()；LinkedHashSet可保持插入顺序去重；distinct()依赖equals/hashCode且不支持字段级去重；SQL层去重优先于Java层。
为什么直接用 HashSet 有时去重失败？
根本原因不是 HashSet 不行，而是你存的对象没正确重写 equals() 和 hashCode()。比如用自定义类 User 存进 HashSet，但没重写这两个方法，那两个字段完全相同的 User 实例仍会被视为不同元素——因为默认比较的是内存地址。
- 只重写
equals()不重写hashCode()：违反哈希契约，可能导致元素“消失”（contains()返回false，但实际存在） - 字段参与比较的，必须全部出现在
hashCode()计算中（推荐用Objects.hash(...)） - 使用 Lombok 的话，加
@EqualsAndHashCode注解最省事，但要确认exclude或of指定的字段符合业务去重逻辑
如何对 List 快速去重并保持插入顺序？
用 LinkedHashSet 是最直接的方式：它既具备 HashSet 的去重能力，又通过链表维护插入顺序。
List<String> original = Arrays.asList("a", "b", "a", "c");
List<String> unique = new ArrayList<>(new LinkedHashSet<>(original));
- 注意：构造
LinkedHashSet时传入原List，会按遍历顺序去重；不能反过来先建空集再addAll()，否则顺序可能错乱 - 如果原
List很大（比如百万级），这种写法会额外分配一次内存；可考虑用Stream+Collectors.toCollection(LinkedHashSet::new)避免中间List -
TreeSet虽然也能去重，但会按自然序或自定义序排序，不保证原始顺序
Stream API 去重时 distinct() 的限制在哪？
distinct() 内部依赖元素的 equals()/hashCode()，和 HashSet 行为一致——所以同样要求对象正确实现这两个方法。它不支持按指定字段去重（比如只看 id 字段）。
- 想按单个字段去重？得自己写
filter()+ 状态容器，例如：Set<Long> seenIds = ConcurrentHashMap.newKeySet(); list.stream() .filter(item -> seenIds.add(item.getId())) .collect(Collectors.toList()); - 用
Collectors.toMap()可实现更灵活的去重逻辑（如保留最新/最早元素），但要注意键冲突时的合并函数 -
distinct()是有状态操作，不能并行流里随意用——虽然它内部做了线程安全处理，但并行下顺序不保证，且性能未必优于单线程
数据库查出来的 List 去重，该在 Java 层还是 SQL 层做？
优先在 SQL 层用 DISTINCT 或 GROUP BY。Java 层去重是兜底手段，不是首选。
立即学习“Java免费学习笔记（深入）”；
- SQL 去重能减少网络传输量、降低 JVM 堆压力，尤其当结果集含大量重复且字段多时
- 如果去重要求复杂（比如“相同 name 下取 created_time 最大的那条”），SQL 用
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)更可靠 - Java 层去重容易掩盖数据一致性问题：比如同名用户本应有唯一 ID，但 DB 里因 bug 出现了两条，Java 层一去重反而让问题更难被发现
真正需要 Java 层去重的场景，往往是多个异构数据源合并后统一清洗，或者业务规则无法用 SQL 表达（比如基于外部服务返回值判断是否重复）。
