java stream的中间操作延迟执行，仅记录逻辑不处理数据，必须由终止操作触发一次性遍历融合处理；中间操作如filter、map返回新stream，终止操作如collect、foreach才启动执行，且stream不可重复使用。
Java Stream 的中间操作不会立刻执行，只有遇到终止操作时，整条流水线才真正启动——不是分步运行，而是一次遍历、融合处理。
中间操作只记不干
filter、map、sorted、limit、skip 等方法都属于中间操作。它们返回新 Stream，但只是把逻辑“记下来”，比如保存一个 Predicate 或 Function 对象，并不访问数据源，也不产生任何结果。
- list.stream().filter(x -> x > 5).map(String::valueOf) 运行完，列表元素一个都没被检查或转换
- 这就像写好菜谱、备好调料，但灶台还没点火
- 可以无限链式调用中间操作，但没终止操作，就等于没做饭
终止操作才是启动开关
collect、forEach、findFirst、count、anyMatch、reduce 等属于终止操作。一旦调用，Stream 才从源头开始，逐个元素流经所有中间操作，边处理边传递，最终产出结果或副作用。
- .findFirst() 或 .anyMatch() 这类短路操作，满足条件就立刻停，不处理后续元素
- .collect(toList()) 或 .count() 这类非短路操作，必须走完整个数据源
- 同一个 Stream 调用两次终止操作会抛 IllegalStateException，需重新 list.stream()
这种设计带来的实际好处
延迟执行不是为了拖时间，而是为效率和灵活性服务：
- 避免多次遍历：传统方式 filter + map 需两轮循环，Stream 在单次遍历中融合完成
- 支持无限流：Stream.iterate(0, i -> i + 1).limit(10) 能安全构造，没终止操作就不会死循环
- 减少内存压力：不缓存中间集合，尤其适合大数据或链式变换场景
- 调试时注意：只写中间操作，断点进不去 lambda；加了 forEach 或 collect 才会触发
容易踩的几个坑
理解执行时机，能避开不少低级错误：
- 写了 filter 和 map 却忘了加 collect 或 forEach —— 代码看似完整，实则什么都没发生
- 在 filter 或 map 的 lambda 里写日志或修改外部变量（副作用），执行时机不可控，可能不执行、执行多次或顺序异常
- 误以为 peek 是用来调试的“安全替代 forEach”，但它仍是中间操作，不接终止操作照样不触发
- 把 Stream 当作可重复使用的对象，其实它是一次性消费品
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
