Stream.concat()适用于两个同类型流的高效拼接，语义清晰且保留SIZED特性；三个及以上流应改用flatMap；来源差异大、需并行或含null时需换用其他策略。
Java 中拼接 Stream 最常用也最直接的方式是 Stream.concat()，但它不是万能的——用对场景才真正高效。
两个流拼接：concat() 是首选
当明确只需合并两个同类型流时，Stream.concat(a, b) 语义清晰、性能稳定，且返回的流保留 SIZED 特性（大小已知），有利于后续优化（如 limit() 提前终止）。
- 必须确保两个流都未被消费过；已调用
forEach、collect等终端操作后，原流不可再复用 - 推荐写法：直接从数据源（如 List、数组）重新创建流，避免流生命周期管理问题
✅ 正确：Stream.concat(list1.stream(), list2.stream()).collect(Collectors.toList())
❌ 错误：Stream.concat(s1, s2)（其中 s1 已执行过s1.forEach(...)） - 若需去重，优先各自去重再拼接：
Stream.concat(a.distinct(), b.distinct()).distinct()效率远高于全量去重
三个及以上流：改用 flatMap 更合理
Stream.concat() 只接受两个参数，强行嵌套（如 Stream.concat(Stream.concat(a,b),c)）不仅可读性差，还会产生多余中间流，增加内存开销。
- 标准做法：用
Stream.of(stream1, stream2, stream3).flatMap(Function.identity())或更简洁的Stream.of(list1, list2, list3).flatMap(List::stream) - 优势：只构建一个外层流，无嵌套开销；天然支持任意数量的数据源
- 注意：返回流不再有
SIZED属性，某些依赖大小的优化可能失效（如并行分片策略）
特殊场景下，concat() 反而该避开
不是所有“合并”都适合 concat。以下情况建议换思路：
立即学习“Java免费学习笔记（深入）”；
- 流来源差异大（比如一个来自本地文件、一个来自远程 HTTP 请求）：concat 会严格串行执行，第二个流要等第一个彻底结束才开始，失败或延迟无法隔离
- 需要并行拉取多个数据源：应分别用
ForkJoinPool或CompletableFuture并发获取流，再统一收集 - 流可能为空或为 null：concat 不做空值防护，易抛
NullPointerException；可用Optional.ofNullable(stream).map(Stream::of).orElseGet(Stream::empty)包装，或直接走Stream.of(a, b).flatMap(Function.identity())（它自动跳过 null 流）
替代方案对比：什么时候选谁
不追求流式处理时，简单合并也可绕过 Stream：
-
addAll()：适合明确修改已有可变集合，且不介意副作用；注意目标集合必须支持添加（不能是Collections.unmodifiableList或Arrays.asList()返回的固定列表） -
Stream.concat()：适合函数式风格、不可变语义、需链式处理（如 filter → map → limit） -
flatMap方式：适合动态数量、来源多样、或需统一异常/空值处理逻辑
