Collectors.toMap() 默认返回无序 HashMap，需用四参数版本指定 LinkedHashMap::new 才能保序；强转无效，且 LinkedHashMap 不兼容并行流，key 冲突时合并逻辑影响值而非插入顺序。
Collectors.toMap() 默认不保证顺序，必须显式指定 Map 类型
Java 的 Collectors.toMap() 默认返回 HashMap 实例，而 HashMap 不维护插入顺序。即使输入流是有序的（比如来自 ArrayList 或 Stream.of()），默认结果也会打乱顺序。这不是 bug，是规范行为——Javadoc 明确写明“返回的 Map 类型未指定”，实际实现就是 HashMap。
要保持顺序，必须通过三参数或四参数重载版本，传入 Supplier 来指定底层容器：
Map<string integer> map = list.stream()
.collect(Collectors.toMap(
Person::getName,
Person::getAge,
(a, b) -> a, // 冲突解决（必须提供，哪怕逻辑简单）
LinkedHashMap::new // ✅ 关键：指定 LinkedHashMap
));</string>
为什么不能只用两参数 toMap() + 中间 cast？
有人试图这样写：(LinkedHashMap。这会抛出 ClassCastException，因为默认返回的是 HashMap，不是 LinkedHashMap，强转必然失败。
- 两参数
toMap()没有暴露 Map 构造方式，无法干预实例类型 - 三参数版本虽支持合并函数，但仍不接受
Supplier，所以也不行 - 只有四参数版本才允许传入
mapFactory—— 这是唯一合法入口
LinkedHashMap 与并行流不兼容
LinkedHashMap 是非线程安全的，且其插入顺序语义依赖于逐个 put 的执行顺序。一旦使用 parallelStream()，收集过程会被分片、并发执行，LinkedHashMap::new 工厂方法无法协调多个线程的插入时序，结果顺序不可预测，甚至可能抛出 ConcurrentModificationException。
如果你需要并行处理又想保序，得换思路：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 先并行处理生成中间对象列表（如
List），再用串行流收集进> LinkedHashMap - 或者改用
Collectors.groupingBy(..., LinkedHashMap::new, ...)配合mapping等组合操作（但适用场景有限） - 确认是否真需要并行：多数保序场景数据量不大，串行反而更稳
key 冲突时的合并逻辑会影响最终 key 数量
即使指定了 LinkedHashMap::new，如果 key 有重复，合并函数（第三个参数）决定哪个 value 留下。例如：
.collect(Collectors.toMap(
p -> p.getName(),
p -> p.getAge(),
(oldVal, newVal) -> oldVal, // 保留第一个出现的 value
LinkedHashMap::new
))
这个合并策略不会改变 key 的插入顺序——重复 key 对应的 entry 不会重新插入，而是就地更新 value，所以顺序仍由首次遇到该 key 的位置决定。但如果合并逻辑是 (a,b) -> b，那后出现的 value 覆盖前一个，key 的“首次出现位置”不变，只是值变了。
容易忽略的一点：如果合并函数返回 null，会导致 NullPointerException，因为 LinkedHashMap.put() 不接受 null value（除非你显式允许，但 toMap 内部不做空值适配）。
顺序这件事，关键不在怎么写 Collectors，而在于你是否清楚自己对“顺序”的定义——是按原始集合索引？按流中首次出现？还是按 key 自然序？LinkedHashMap 只负责记住你 put 的顺序，它不管你是从哪来的。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
