stream.concat()用于拼接两个同类型stream，不支持null或已关闭流，拼接前流不可耗尽，且需注意内存与资源边界。
Stream.concat() 的基本用法和限制
Stream.concat() 是 Java 8 引入的静态方法，用于把两个 Stream 拼接成一个新流。它不修改原流，也不支持三个及以上流直接拼接——必须嵌套调用，比如 Stream.concat(a, Stream.concat(b, c))。
常见错误是传入 null 流：如果任一参数为 null，会直接抛出 NullPointerException，不是懒求值阶段报错，而是在调用 concat 时就触发。
- 两个流必须是同一泛型类型，比如不能拼接
Stream<string></string>和Stream<integer></integer> - 若其中一个流已关闭（如来自已关闭的文件通道），拼接后首次操作可能抛出
IllegalStateException - 拼接后的流仍保持懒求值特性，但头一个流必须完全消费完，才会拉取第二个流的数据
合并前需确保流未被消费过
Java 中的 Stream 是一次性使用的。一旦调用了 forEach、collect、count 等终端操作，该流就“耗尽”了，再次使用会抛出 IllegalStateException: stream has already been operated upon or closed。
典型误写：
Stream<string> s1 = Stream.of("a", "b");
Stream<string> s2 = Stream.of("c", "d");
s1.forEach(System.out::println); // 这里已消费 s1
Stream<string> merged = Stream.concat(s1, s2); // 报错</string></string></string>
正确做法是：在拼接前保留原始数据源，或用 Supplier 重新生成流：
- 用集合重构建：
Stream.concat(list1.stream(), list2.stream()) - 用 Supplier 延迟创建：
Stream.concat(() -> s1, () -> s2).get()（需自行封装） - 对复杂逻辑，优先考虑先
collect到List再转流，避免流生命周期管理问题
替代方案：何时不该用 Stream.concat()
当两个流来源差异大（比如一个来自数据库查询，一个来自 API 调用），且存在失败风险或耗时差异时，Stream.concat() 可能掩盖问题：它不会并行拉取，也不会自动处理异常，第二个流的初始化延迟会卡在第一个流结束之后。
更稳健的选择包括：
- 用
Stream.of(s1, s2).flatMap(Function.identity())—— 语义更清晰，且可配合Optional.stream()安全处理可能为空的流 - 需要并行合并时，改用
ForkJoinPool分别处理再收集，而不是依赖 concat 的顺序性 - 若目标是去重合并，直接用
Stream.concat(a, b).distinct()效率低（需遍历全部元素），不如先各自去重再拼接
实际例子：合并日志流并按时间排序
假设你有两个日志流，分别来自本地文件和远程服务，都返回 LogEntry 对象，需统一排序后输出前 10 条：
Stream<logentry> localLogs = Files.lines(Paths.get("app.log"))
.map(LogEntry::parse)
.filter(Objects::nonNull);
Stream<logentry> remoteLogs = fetchFromApi().stream();
// ✅ 正确：拼接后立即排序（注意 sorted() 要求 LogEntry 实现 Comparable 或传 Comparator）
Stream<logentry> merged = Stream.concat(localLogs, remoteLogs)
.sorted(Comparator.comparing(LogEntry::getTimestamp))
.limit(10);
merged.forEach(System.out::println);</logentry></logentry></logentry>
注意这里隐含一个关键点：如果 localLogs 是基于大文件的无限流（未加 limit），sorted() 会尝试缓存全部元素——这可能导致 OOM。真实场景中，应先各自截断再合并，或改用优先队列分批归并。
真正容易被忽略的不是语法，而是流的“边界感”：concat 不是管道焊接，而是调度契约——它承诺顺序，但不承诺资源、延迟或内存安全。
