Java Stream 分组后如何保持输入顺序：groupingBy 与 LinkedHashMap 的选择

订单状态统计经常要先分组，再按页面展示顺序输出。代码看起来只是把 Collectors.groupingBy 换进 Stream，但如果直接使用默认重载，结果类型通常是 HashMap，输入列表的首次出现顺序并没有被保存。要稳定保留“待支付、处理中、已完成”这样的业务顺序，需要显式传入 LinkedHashMap::new，或者在分组之后做一次明确排序。

先复现：分组结果为什么不能直接当展示顺序

假设页面收到一批已经按业务优先级排列好的订单：

record Order(String id, String status) {}

List orders = List.of(
    new Order("A-01", "待支付"),
    new Order("B-02", "处理中"),
    new Order("A-03", "待支付"),
    new Order("C-04", "已完成")
);

大家最常用的最简分组写法是：

Map> grouped = orders.stream()
    .collect(Collectors.groupingBy(Order::status));

这里的问题不是分组得到的内容有错，而是返回的 Map 本身没有维持输入顺序的公开承诺。后续你换了不同版本JDK、数据量变大或者哈希分布发生变化时，遍历键的顺序根本没法匹配页面的展示约定。哪怕本地调试时打印出来的结果是对的，也不能当做验收标准，测试用例必须直接显式断言键的顺序是否符合要求。

第一层检查：把 LinkedHashMap 传给 groupingBy

groupingBy 有一个接收 mapFactory 的重载。把结果容器换成 LinkedHashMap 后，分组键会按照第一次出现的顺序进入 Map：

Map> grouped = orders.stream()
    .collect(Collectors.groupingBy(
        Order::status,
        LinkedHashMap::new,
        Collectors.toList()
    ));

System.out.println(grouped.keySet());
// [待支付, 处理中, 已完成]

注意这个顺序的来源是输入数据里分组键的首次出现位置。后续输入里第二个“待支付”元素不会再次把对应键移动到Map末尾，它只会向已有的元素List里追加当前数据。

如果只需要默认的下游收集器，也可以直接写成两参数的重载形式：

Map> grouped = orders.stream()
    .collect(Collectors.groupingBy(
        Order::status,
        LinkedHashMap::new
    ));

第二层检查：输入顺序和业务排序不是一回事

LinkedHashMap 解决的是“按照输入首次出现顺序保存键”。如果页面规定无论输入如何都必须显示“待支付、处理中、已完成”，那就应该把排序规则写出来，而不是依赖上游列表刚好排好：

List statusOrder = List.of("待支付", "处理中", "已完成");
Map rank = IntStream.range(0, statusOrder.size())
    .boxed()
    .collect(Collectors.toMap(statusOrder::get, Function.identity()));

Map> sorted = orders.stream()
    .collect(Collectors.groupingBy(Order::status))
    .entrySet().stream()
    .sorted(Map.Entry.comparingByKey(Comparator.comparingInt(rank::get)))
    .collect(Collectors.toMap(
        Map.Entry::getKey,
        Map.Entry::getValue,
        (left, right) -> left,
        LinkedHashMap::new
    ));

这段代码的意图更清楚：先完成分组，再根据业务字典排序，最后用 LinkedHashMap 固定排序后的输出。若出现字典里不存在的状态，rank::get 会返回空值，生产代码应先做未知状态兜底。

第三层检查：下游收集器会不会改变你想要的顺序

Map 的键顺序和每个键下面的元素顺序是两个问题。默认的 Collectors.toList() 在顺序流里会保留元素遇到顺序；如果改成 toSet()，集合内部顺序就不应再被当成展示契约。

Map> idsByStatus = orders.stream()
    .collect(Collectors.groupingBy(
        Order::status,
        LinkedHashMap::new,
        Collectors.mapping(Order::id, Collectors.toList())
    ));

使用并行流的时候还要额外留意：即使最终指定的容器是 LinkedHashMap，也不应该把并行收集后得到的顺序当成跨运行环境、跨版本的稳定业务保证。需要输出稳定排序结果时，优先使用顺序流处理，或者收集完成后再按明确的业务规则重排。

用测试把顺序边界钉住

@Test
void keepsFirstSeenGroupOrder() {
    Map> result = orders.stream()
        .collect(Collectors.groupingBy(Order::status, LinkedHashMap::new,
            Collectors.toList()));

    assertEquals(List.of("待支付", "处理中", "已完成"),
        new ArrayList(result.keySet()));
    assertEquals(List.of("A-01", "A-03"),
        result.get("待支付").stream().map(Order::id).toList());
}

还应该补充一个修改输入顺序的测试用例，先确认团队实际要的是“按键首次出现顺序输出”还是“按固定业务顺序输出”。这两个需求都能用Map实现，但对应的编写方式和验收标准完全不同。

常见误区与最终判断

把 HashMap 当前一次输出的顺序写进快照测试，是最常见的误区；它测试的是实现偶然性，不是业务规则。另一个误区是只把外层 Map 换成 LinkedHashMap，却在下游使用无序 Set，结果页面中的分组键稳定了，组内订单仍然抖动。

判断方式可以压缩成三句：要保留输入首次出现顺序，用 LinkedHashMap::new；要遵循业务优先级，收集后按字典排序；要保证组内元素顺序，就保留顺序流并选择有序下游收集器。把这三个边界写进测试，后续替换数据源或打开并行处理时才不容易埋下隐患。

常见问题

groupingBy 默认一定返回 HashMap 吗？

默认分组常用实现返回 HashMap，但业务代码不应该依赖其内部具体实现或者碰巧出来的遍历顺序。需要顺序输出时，显式传入自定义 Map 工厂就可以。

LinkedHashMap 能保证业务优先级吗？

不能。LinkedHashMap 保证的只是插入顺序；要实现自定义业务优先级排序，需要额外传入显式的 Comparator 或者维护单独的排序字典。

什么时候应该用 TreeMap？

当键本身有自然排序规则，或者你准备了对应的 Comparator 时可以使用 TreeMap。它是按键的排序规则组织元素，不会保留输入里键的首次出现顺序。

小结：先确定顺序的来源，再选择收集器。顺序来自输入，就使用 LinkedHashMap；顺序来自业务，就把排序规则写进代码和测试。