Stream中间操作不触发实际计算，仅组装流水线；终结操作（如collect、findFirst）才启动执行，且Stream只能消费一次。
Stream 中间操作真的不执行？
不是“不执行”，而是不触发实际计算——所有 filter、map、sorted 这类中间操作只是把操作逻辑记下来，组装成一个流水线。真正干活的是 collect、forEach、findFirst 这些终结操作。
常见错误现象：System.out.println 放在 map 里没输出，以为代码没跑；或者误以为 stream.filter(...).map(...) 立刻遍历了全部元素。
- 只有终结操作调用时，整个流水线才从头开始拉取数据、逐层处理
- 如果终结操作是短路的（如
findFirst），后续元素可能根本不会进入filter或map - 多次调用同一个 Stream 实例会抛
IllegalStateException，因为 Stream 只能消费一次
为什么 map 后 filter 顺序会影响性能？
中间操作的顺序直接影响数据流过流水线的量，尤其在有状态操作（如 sorted）或开销大的函数时。
使用场景：处理百万级日志列表，先 filter 再 map，比反过来快一个数量级。
立即学习“Java免费学习笔记（深入）”；
-
stream.filter(x -> x.isValid()).map(x -> heavyTransform(x))：只对有效项做转换 -
stream.map(x -> heavyTransform(x)).filter(y -> y != null)：每个原始项都先执行heavyTransform，哪怕最后被过滤掉 -
sorted是有状态操作，必须等上游全部数据就位才能开始，放前面会阻塞整个流水线
peek 能不能代替 debug 日志？
可以临时用，但不能当正式调试手段——peek 只在流水线实际执行时触发，且行为依赖终结操作是否执行、是否短路。
常见错误现象：加了 peek(System.out::println) 却没打印；或在并行流中输出顺序混乱、甚至重复。
-
peek不改变元素，纯副作用，适合观察；但不要在里面修改对象状态（尤其并行流） - 并行流下
peek的执行时机和线程不可控，日志可能穿插、丢失、重复 - 生产环境禁用
peek做业务逻辑，JVM 可能在优化时移除无副作用的peek（虽然目前不会，但语义上不保证）
collect(Collectors.toList()) 和 forEach 有什么本质区别？
前者构建新容器，后者只消费；但更关键的是：前者强制触发完整流水线，后者也触发，但无法返回结果。
性能影响：在大数据量下，collect 需要分配内存、扩容、复制；forEach 如果只是发消息或写 DB，可能更轻量。
-
forEach不保证顺序（并行流下），collect(toList())保持原始顺序（即使并行流） -
forEach无法中断（除非抛异常），而anyMatch、findFirst这类短路终结操作可提前退出 - 别用
forEach+ 外部变量收集结果——这破坏 Stream 的函数式语义，且在并行流中出错
惰性求值不是魔法，是延迟绑定执行时机；真正容易被忽略的，是「终结操作决定整条链是否运转」这个前提——漏掉它，所有中间操作都只是内存里的一个对象图，连一行业务代码都没跑。
