Java中Stream.distinct()去重需重写equals()和hashCode()方法且逻辑一致，仅重写equals()会导致HashSet失效；应基于业务字段（如id）实现，避免可变字段，并可通过distinctByKey等替代方案处理无法修改原类的情况。
在 Java 中，Stream.distinct() 默认基于对象的 equals() 和 hashCode() 判断是否重复。要对复杂对象（如自定义类）正确去重，必须重写这两个方法，并确保逻辑一致——这是核心前提。
重写 equals() 和 hashCode() 是必要基础
仅重写 equals() 不够，hashCode() 必须同步实现，否则 distinct() 在底层使用 HashSet 时可能失效（相同对象 hash 不同，被当作不同元素）。
建议使用 IDE 自动生成（如 IntelliJ 的 Alt+Insert），或用 Objects.equals() 和 Objects.hash() 手动编写，确保只参与业务上“视为相同”的字段：
- 例如
User类按id去重 →equals和hashCode只比较/计算id - 若按
name + email去重 → 两个方法中都只涉及这两个字段 - 避免包含可变字段（如状态、时间戳），否则对象修改后 hash 变化，破坏集合一致性
distinct() 直接用于对象流，无需额外收集器
只要 equals()/hashCode() 正确，调用 stream.distinct() 即可完成去重，返回新流：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
List<User> users = Arrays.asList(
new User(1, "Alice", "a@x.com"),
new User(2, "Bob", "b@x.com"),
new User(1, "Alice", "a@y.com") // id 相同，视为重复
);
List<User> unique = users.stream()
.distinct()
.collect(Collectors.toList()); // 结果含 2 个对象（id=1 和 id=2 各一个）
注意：distinct() 是有状态中间操作，依赖内部 HashSet 缓存已见元素，内存占用随唯一元素数增长。
替代方案：当无法修改原类时用 keyMapper
如果不能或不应修改目标类的 equals()（如第三方类、或需多种去重逻辑），可用 Collectors.toMap() 或自定义收集器，但更推荐借助 StreamEx 库的 distinctByKey()，或手写基于 key 的去重：
- 用
Map记录已见 key（如user.getId()），过滤重复 - 或用
Collectors.collectingAndThen(..., ArrayList::new)配合LinkedHashSet保证顺序 - 纯 Stream API 下，较简洁的方式是：
stream.filter(distinctByKey(User::getId))，其中distinctByKey返回一个Predicate，利用ConcurrentHashMap记录已见 key
常见陷阱与验证建议
去重失败往往源于细节疏忽：
-
没重写
hashCode()→ 表现为“应该去重却没去” -
equals()中用了==比较字符串或包装类型 → 应用Objects.equals(a, b) - 字段为
null时未处理 →Objects.equals()安全，手动比较需判空 - 测试时用
System.out.println(list)看结果，但没重写toString()→ 看不出是否真去重，建议打印关键字段
简单验证：构造含明确重复（相同 id 或相同业务字段）的对象列表，执行 distinct() 后检查 size 和内容即可确认效果。
