Stream.distinct()不保证顺序，仅在有序流中保留首次出现元素；并行流下顺序失控，需用LinkedHashSet手动去重或Collectors.toMap按字段去重。
Stream.distinct() 为什么有时不保持顺序
distinct() 确实依赖元素的 equals() 和 hashCode()，但它本身不保证顺序——除非底层数据源是有序流（比如来自 ArrayList 的 stream）。问题常出在你误以为它“自动稳定”，其实它只是按遍历顺序去重：遇到重复元素时，**只保留第一次出现的那个**，所以「看起来」有序。但一旦上游被并行化（parallelStream()），顺序就不可控了。
- 别用
parallelStream().distinct()做需保序的去重，结果随机 - 确认你的原始
List是ArrayList或其他有序实现；LinkedList也行，但CopyOnWriteArrayList在迭代中修改会引发问题 - 如果元素类型没重写
equals()/hashCode()，distinct()按引用比较，基本等于没去重
用 LinkedHashSet 手动去重更可控
手动构造 LinkedHashSet 是最直白、最易调试的方式，尤其当你需要对去重逻辑微调（比如忽略大小写、按某字段判重）时，比纯 Stream 更灵活。
-
new LinkedHashSet(list)一行搞定，且天然保持插入顺序 - 它不依赖
stream()，也不受并行影响，适合在工具方法里复用 - 注意：如果
list含null，LinkedHashSet允许一个null，没问题；但某些自定义判重逻辑可能要单独处理null - 性能上，比
distinct()多一次遍历和哈希表插入，但差异极小，可忽略
按对象字段去重必须自己写 Collectors
原生 distinct() 只能基于整个对象判等，没法指定「用 id 字段去重」。这时候得用 Collectors.toCollection() 配合 LinkedHashSet，或用 Collectors.collectingAndThen() 包一层。
- 推荐写法：
list.stream() .collect(Collectors.collectingAndThen( Collectors.toCollection(() -> new LinkedHashSet<>()), ArrayList::new ));——但这是全对象去重 - 按字段去重示例（去重 key 为
user.getId()）：list.stream() .collect(Collectors.collectingAndThen( Collectors.toMap(User::getId, Function.identity(), (a, b) -> a), map -> new ArrayList<>(map.values()) ));注意：这个方案会丢弃后出现的重复项，且要求getId()非空 - 如果字段可能为
null，toMap会抛NullPointerException，得先过滤或用Objects.toString(id)转换
distinct() 和 LinkedHashSet 的兼容性陷阱
两者都依赖 equals()/hashCode()，但行为边界不同：比如你重写了 equals() 却忘了同步改 hashCode()，LinkedHashSet 可能漏掉重复项；而 distinct() 在这种情况下也可能失效，但更难定位。
立即学习“Java免费学习笔记（深入）”；
- 测试时务必用含重复元素的真实数据，不能只靠单元测试 mock 对象
- 若类来自第三方库（如 Lombok 生成的
@Data），确认它确实生成了hashCode()；@EqualsAndHashCode默认包含所有非静态非瞬态字段，但显式 exclude 了某些字段就容易踩坑 - Stream 去重是惰性的，错误只在终端操作（如
collect()）时暴露；LinkedHashSet构造是立即执行的，失败更早可见
LinkedHashSet 构造；想链式写、且对象已正确定义等价逻辑，distinct() 更简洁。但只要涉及字段判重，就得绕开原生 distinct()，自己组织收集逻辑。 
