Stream.concat仅支持两路流拼接，多流合并推荐Stream.of+flatMap；concat适用于已构建的带状态流复用，后续链式操作需按需collect以避免重复计算。
Stream.concat 本身不支持多个流直接合并，它只接受两个 Stream 参数。所谓“多个流变量的无损合并”，关键不在强行用 concat 套娃，而在于**明确目标、选对入口、避免中间损耗**——尤其当后续还要接 filter、map、collect 等链式操作时。
先认清 concat 的边界：它只做两路拼接
Stream.concat(a, b) 返回一个新 Stream，元素顺序是 a 全部 + b 全部，不修改原流，也不去重、不排序。它的设计就是轻量缝合，不是聚合中枢。
常见误用：
- 写成 Stream.concat(a, b, c) → 编译失败，方法签名不支持可变参数
- 写成 Stream.concat(a, Stream.concat(b, c)) → 虽能运行，但嵌套生成临时流对象，SIZED 特性逐层衰减，且代码可读性差
- 漏掉 .collect(Collectors.toList()) 就调用 .size() 或 get() → 运行时报错，因为返回的是 Stream，不是 List
多个流变量合并，推荐用 Stream.of + flatMap
当你手头有 list1、list2、list3 …… 这类明确的多个 List 变量，最自然、无损、可读性强的方式是：
- 用 Stream.of(list1, list2, list3) 把它们装进一个外层 Stream
- 再用 .flatMap(List::stream) 展平成单层元素流
- 后续所有操作（filter/map/limit/collect）都可无缝衔接
示例：
.flatMap(List::stream)
.filter(x -> x > 0)
.map(x -> x * 2)
.collect(Collectors.toList());
这种方式保留了所有原始数据，不改变顺序，无副作用，且 flatMap 后的流仍支持并行处理（若源 List 支持）。
concat 仍有不可替代的场景
当你要合并的不是“多个 List”，而是**已构建好的、带状态或中间操作的 Stream 实例**（比如过滤后、映射后的流），concat 就更合适：
- streamA = users.stream().filter(u -> u.isActive()).map(User::getName)
- streamB = guests.stream().filter(g -> g.isVerified()).map(Guest::getAlias)
- 合并只需：Stream.concat(streamA, streamB).distinct().sorted().toList()
这种写法不回溯源头 List，不重复执行 map/filter，真正实现“流级复用”。注意：concat 后的流依然惰性求值，后续链式操作不会提前触发计算。
后续逻辑链处理的关键提醒
合并只是起点，后续怎么链，直接影响性能和语义：
- 要随机访问或多次遍历？ 必须 .collect 成集合（如 toList()），否则每次 forEach 都会重跑整个流水线
- 只遍历一次且无需索引？ 直接 .forEach(...) 或 .count()，跳过 collect，减少内存分配
- 需去重或排序？ distinct() 和 sorted() 应放在 collect 前；若已 collect 成 List，再 new TreeSet 或 Collections.sort 效率更低
- 下游是数据库插入或 HTTP 批量调用？ 用 .collect(Collectors.groupingBy(...)) 或 .collect(Collectors.partitioningBy(...)) 预分组，比在 forEach 里手动攒批更安全
