使用Stream.concat()合并集合是否存在弊端？

当你想用Stream.concat()一行代码合并两个集合时，维护者改成传统的构造器+addAll()写法，通常是出于以下几个实际考量：

1. 性能与内存开销更高 #

Stream.concat()本质是创建了一个串联两个流的包装对象，后续的collect()过程还要经历流框架的迭代、收集逻辑，这会带来额外的对象创建和抽象层开销。而传统写法：

Collection<SomeType> mergedCollection = new ArrayList<>(collection);
mergedCollection.addAll(anotherCollection);

直接依赖集合底层实现的批量操作——比如ArrayList的构造器会直接复制原集合的数组，addAll()也是批量扩容添加元素，整个过程是纯集合层面的高效操作，没有流框架的额外损耗，在元素数量较多时，性能差异会更明显。

2. 集合实现类型更可控 #

用Stream.concat().collect(...)时，如果使用默认的Collectors.toList()，返回的集合类型是不确定的（Java 8中是ArrayList，但Java 9+之后Collectors.toList()返回的是不可变List；如果用其他Collector，结果类型更不可控）。而传统写法直接指定了集合的具体实现（比如ArrayList、LinkedHashSet），能明确控制最终集合的特性：比如是否可变、是否支持随机访问、是否保持插入顺序等，避免后续因集合类型不一致引发的隐性问题。

3. 代码直观性与维护成本 #

虽然Stream.concat()一行代码看起来简洁，但对于不熟悉Stream API的开发者来说，构造器+addAll()的写法更直白——一眼就能看懂是“创建新集合，先放入第一个集合的元素，再添加第二个集合的元素”。在团队协作场景下，这种直白的代码更易于理解和维护，减少因流操作的抽象性带来的沟通成本。

补充：Stream.concat()的适用场景 #

当然，Stream.concat()并非完全不可用：如果合并集合后还需要进行其他流操作（比如过滤、映射、去重），那么用Stream.concat()可以直接串联这些操作，代码的连贯性更好。但单纯合并两个集合到新集合的场景下，传统写法确实是更务实的选择。

内容的提问来源于stack exchange，提问作者Powet