终止操作是stream执行的真正起点，它触发数据源遍历与流水线串行处理，中间操作仅构建逻辑链；每元素依次经filter、map等处理，短路操作可提前终止；泛型类型随操作变化体现数据形态，stream不缓存中间结果。
Stream终止操作是整个流式处理的“开关”，它不光决定中间操作何时执行，更控制着数据在每一步中的形态变化和流转路径。要真正掌握变量流转全过程，关键不是背方法名，而是看清“谁在什么时候拿到什么数据、又传给谁”。
终止操作才是真正的执行起点
中间操作（如filter、map、sorted）只是构建一个操作描述链，不碰原始数据，也不生成新集合。它们返回的仍是Stream对象，但内部只存逻辑指令。只有终止操作（如collect、forEach、findFirst、count）被调用时，Stream才从数据源拉取元素，按定义好的顺序逐个推入流水线。
- 整个过程只遍历一次数据源，不是每个中间操作都扫一遍
- 每个元素“进流水线→过filter→过map→过limit…”是一路串行完成的，不是分阶段批量处理
- 一旦某个短路操作（如findFirst、anyMatch）满足条件，后续元素就不再进入流水线
看懂变量在每一步的类型与值变化
变量流转的本质，是泛型类型T在各操作间的转换过程。例如：
List<user> users = ...; Stream<user> s1 = users.stream(); // T=User Stream<user> s2 = s1.filter(u -> u.getAge() > 18); // T=User Stream<string> s3 = s2.map(u -> u.getName()); // T=String List<string> result = s3.collect(Collectors.toList()); // 终止：输出List<string></string></string></string></user></user></user>
每一步的Stream泛型都明确体现当前数据形态。map之后，下游接收到的不再是User对象，而是String；如果后续误写成map(u -> u.getAge())，编译器立刻报错——这就是类型安全带来的流转可见性。
调试时重点关注Sink链与实际执行顺序
底层中，Stream通过Sink（接收器）串联操作：上游Sink.accept() → 触发本层逻辑 → 调用下游Sink.accept()。你可以用带日志的lambda验证执行节奏：
- filter里打印：“过滤 [name]，年龄=[age]”
- map里打印：“转换 [name] → 大写”
- 再加limit(2)，会发现只看到前两个匹配元素的完整日志，第三个即使满足filter也不会进map
这种输出不是“先列所有过滤结果，再统一转换”，而是“来一个、判一个、转一个、攒一个”，直观反映变量逐个流转的真实路径。
避免常见误解：Stream不是集合，也不缓存中间结果
有人以为s1.filter(...).map(...)后，内存里已存在一个“过滤+转换后的临时列表”。其实没有。Stream不保存任何中间数据，原始集合未变，中间步骤也无实体容器。终止操作触发时，数据是实时流动的：
- source → filter → map → collect：数据像水一样流过每一关
- parallelStream下，数据被分区，但每个分区仍保持“单元素流水线”行为
- 一旦collect执行完毕，Stream对象即失效，再次调用会抛IllegalStateException
