java stream api执行分构建与执行两阶段，核心是延迟执行：中间操作仅构建流水线，终端操作才触发按需计算；闭包受限于effectively final规则，lambda捕获的局部变量不可修改。
Java Stream API 的执行过程不是“一气呵成”，而是分构建阶段和执行阶段，延迟执行（lazy evaluation）是它的核心特征；闭包在 Stream 中主要体现为对局部变量的捕获，但受限于 effectively final 规则，并非传统函数式语言中的自由闭包。
Stream 的执行分两步：构造流水线 + 触发终端操作
创建 Stream（如 list.stream()）或调用中间操作（如 filter、map）时，只是组装一个操作链（Pipeline），不真正处理数据。只有遇到终端操作（如 collect、forEach、count），才会从源头开始，按需拉取、逐级处理元素。
- 中间操作返回新 Stream，可链式调用，但不会触发计算
- 终端操作消费 Stream，导致整个流水线“启动”，且只能被调用一次
- 短路操作（如
findFirst、anyMatch）可能提前结束遍历，提升效率
Stream 中的“闭包”本质是变量捕获，受 effectively final 约束
Stream 的 lambda 表达式或方法引用会访问外部作用域的变量，比如：
int threshold = 10;
list.stream().filter(x -> x > threshold).collect(...);
这里 threshold 被 lambda 捕获。Java 不允许修改该变量（编译时报错），除非它满足 effectively final —— 即声明后未再赋值，哪怕没加 final 关键字。
- 不能在 lambda 内部修改外部局部变量（如
threshold++是非法的） - 实例字段或静态变量不受此限，但易引发线程安全或状态混乱问题，应避免
- 若需累积状态，优先用终端操作（如
reduce）或收集器（Collectors.summingInt），而非依赖外部变量
常见误区：误以为 map/filter 立即执行或可重复使用 Stream
写完 stream.map(...) 并不意味着数据已被转换；多次调用同一个 Stream 的终端操作会抛 IllegalStateException。
- Stream 不是集合，不可复用；重复使用需重新创建（如再调一次
list.stream()） - 调试时不要靠
System.out.println在中间操作里“看结果”，它只在终端触发时才执行 - 并行 Stream（
parallelStream()）虽能利用多核，但要求操作无状态、无副作用，否则结果不可预测
闭包相关面试延伸点：为什么不能捕获非 final 局部变量？
这是 JVM 实现决定的：lambda 编译后本质是合成的私有方法，捕获的变量以方法参数形式传入。如果允许修改，会导致栈上变量与 lambda 内副本不一致，破坏内存模型一致性。
- 设计初衷是保证函数式语义的确定性与线程安全性
- 若真需可变状态，可用线程安全容器（如
AtomicInteger）包装，但通常说明设计偏离了函数式原则 - 对比 Kotlin 或 Scala 的真正闭包，Java 的限制更严格，也更利于静态分析与优化
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
