stream的中间操作仅登记处理逻辑而不执行，终端操作才触发实际数据处理；中间操作延迟执行、可优化合并、避免冗余集合创建，并通过泛型变化保障类型安全。
因为 Stream 的中间操作本身不处理数据，只登记“接下来要做什么”，真正驱动数据流动的，是终端操作这个“启动开关”。没有它，整条流水线就只是纸面计划，不会跑起来。
中间操作只是记账，不是干活
调用 filter、map、sorted 这些方法时，Stream 并不会去遍历集合、筛选元素或转换值。它只是把你的逻辑（比如 “年龄大于18”）封装成一个步骤，追加到内部的操作链里。整个过程不消耗 CPU，也不访问原始数据。
- 就像写好一份菜谱，但还没点火炒菜
- stream.filter(x -> x > 0).map(String::valueOf) 执行完，控制台不会打印任何东西，集合也毫发无损
- 此时的 Stream 实例仍处于“待命”状态，可以继续接更多中间操作
终端操作才是真正的发令员
collect、forEach、count、findFirst 这类方法一出现，Stream 就开始从头执行整条流水线：挨个取源数据里的元素，依次过 filter → map → … → 最终归集或消费。
- 执行
.collect(Collectors.toList())后，filter 和 map 才真正运行，且是一个元素走完全部步骤，再处理下一个 - 短路操作（如 findFirst）可能中途停下，但依然会触发前面部分的执行
- 一旦执行过终端操作，该 Stream 就失效，再调用任何操作都会抛 IllegalStateException
这种设计带来实实在在的好处
延迟执行不是为了制造麻烦，而是为性能和灵活性服务：
- 多个中间操作可被自动优化合并（比如连续两个 map 可能被融合）
- 避免创建不必要的中间集合，节省内存
- 支持并行流的智能分片与结果合并
- 配合短路操作（limit、anyMatch），能在满足条件时立刻停止，不用扫完整个数据源
类型安全帮你看清流转路径
每一步中间操作都会改变 Stream 的泛型类型，编译器据此检查后续操作是否合法：
-
stream.filter(u -> u.getAge() > 18)→ 还是Stream<user></user> -
.map(u -> u.getName())→ 变成Stream<string></string> - 如果之后误写
.map(s -> s.getAge())，编译直接报错：String 没有 getAge 方法
这种类型流转让整个数据变形过程清晰可见，减少隐式错误。
