Stream延迟执行指构建操作链后暂存，仅在终端操作时单次遍历执行全链，避免多次遍历与中间集合开销，并支持短路优化。
Stream流的延迟执行特性不是“等一会儿再做”，而是“先记下来，等真要结果时才统一算”。它不立即处理数据，而是构建操作链，把filter、map这些中间动作暂存起来，直到遇到count、collect、findFirst这类终端操作，才从头开始一次性遍历并执行整条流水线。这种机制天然支持优化，比如循环融合、短路跳过、减少冗余遍历。
延迟执行如何减少实际遍历次数
传统写法中，先用for循环filter一遍得到新列表，再对新列表map一遍，等于遍历两次。而Stream把filter和map编排进同一条流水线后，JVM会在终端操作触发时，对每个元素依次执行filter判断→（若通过）再执行map转换，全程只遍历原始集合一次。这省掉了中间集合的创建与反复迭代开销。
- 例如：
list.stream().filter(x -> x > 5).map(x -> x * 2).collect(...)，底层是单次遍历完成过滤+转换 - 若把
map放在filter前面，所有元素都会先计算平方，哪怕后续被filter掉——白白浪费CPU - 所以应优先把计算成本低、筛选力度大的操作（如filter）前置，尽早缩小数据规模
短路操作让延迟执行更聪明
像findFirst()、anyMatch()、limit(10)这类终端操作具备短路能力：一旦满足条件就立刻停止处理，不再触碰剩余元素。配合延迟执行，意味着整个流水线可能只跑前几个元素就结束，大幅降低负载。
-
stream.filter(...).map(...).findFirst()：找到第一个匹配项即停，后续元素完全不参与任何中间操作 -
stream.sorted().findFirst()是个陷阱——sorted()必须加载全部数据才能排序，无法短路，会抵消短路优势 - 避免在短路链路中混入
sorted、distinct等需全量缓存的中间操作
变量处理效率提升的关键实践
延迟执行本身不提速，真正提效的是你如何组织操作链。重点不在“用了Stream”，而在“怎么串”。
- 把高开销操作（如远程调用、复杂正则匹配）尽量往后放，或用
peek()调试确认是否被短路跳过 - 对小数据集（
- 并行流（
parallelStream()）不是银弹：仅当操作无状态、无副作用且数据量足够大时才考虑，否则线程调度开销反而拖慢速度
延迟执行是Stream高效的基础，但真正释放性能，靠的是理解每一步操作的代价和依赖关系，然后把它们串成一条“能早停、少计算、一次过”的流水线。
