Java Stream中间操作惰性求值，仅构建流水线；终端操作触发一次性融合执行，支持短路与优化，流不可重复使用。
Java Stream API 的中间操作链不会立即执行，而是构建一条待触发的流水线；只有终端操作启动时，整条链才按需、一次性地协同运行。
中间操作只是“登记”，不干活
filter、map、sorted 等中间操作返回的是新 Stream，它们只记录要做什么，并不处理数据。就像写好一张菜谱，但厨房还没开火。
- 调用
stream.filter(...).map(...).sorted(...)时，控制台不会打印任何日志，也没有元素被真正过滤或转换 - 此时 Stream 处于“准备就绪”状态，内部保存着操作描述和原始数据源引用
- 同一个 Stream 实例不能重复使用——一旦被终端操作消耗，再调用就会抛
IllegalStateException
终端操作才是“发令枪”
forEach、collect、count、findFirst 这类终端操作一执行，整个中间链才真正运转起来，而且是融合式执行，不是逐个遍历。
- 例如
stream.filter(p).map(f).collect(toList())：底层会尝试把 filter 和 map 合并成一次遍历，避免生成中间集合 - 短路操作（如 anyMatch、findFirst）可能提前结束，不处理剩余元素；非短路操作（如 collect、count）必须走完全程
- 终端操作执行后，Stream 就失效了，不能再参与后续链式调用
操作顺序影响实际性能
中间操作的排列不是随意的，位置不同，计算量可能差很多。
立即学习“Java免费学习笔记（深入）”；
- 把 filter 放在 map 前面，能减少需要映射的元素数量——先筛再转，更省资源
- distinct 和 sorted 都是有状态操作，它们会缓冲全部数据，放在链尾比放中间更可控
- limit 和 skip 属于切片操作，配合 short-circuiting 终端操作（如 findFirst）可大幅缩短执行路径
常见误区与验证方式
靠打印日志或断点是最直接的验证手段，能清楚看到“何时执行”。
- 在 filter 或 map 的 lambda 里加
System.out.println，只在终端操作调用时输出，证明惰性求值 - 连续两次调用
forEach会报错，说明 Stream 不可重用 - 对 parallelStream 使用 peek 查看线程行为，可观察并行分段处理痕迹
