函数式接口是Stream流的操作引擎和生命周期支撑——filter用Predicate、map用Function、forEach用Consumer、generate用Supplier，接口类型决定行为边界，选错会导致编译失败或语义错误。
函数式接口是 Stream 流的“操作引擎”——Stream 本身不干活，真正执行过滤、转换、消费等动作的，全是背后绑定的函数式接口实例。
Stream 的每个操作都对应一个函数式接口
Stream 的中间操作和终止操作，本质上就是接收特定函数式接口作为参数，并调用其抽象方法：
-
filter() 接收
Predicate：判断元素是否保留（test(T t)返回 boolean） -
map() 接收
Function：把一个类型元素转成另一个类型（apply(T t)返回 R） -
forEach() 接收
Consumer：对每个元素执行副作用操作（accept(T t)无返回） -
findFirst() / findAny() 虽无显式参数，但内部依赖
Predicate配合Optional实现短路匹配 -
reduce() 使用
BinaryOperator（即Function）做累积计算
Lambda 和方法引用让接口调用变得轻量
没有函数式接口，你就得写一堆匿名内部类；有了它，就能用一行 Lambda 或方法引用完成逻辑表达：
比如筛选长度大于 2 的字符串：
list.stream()
.filter(s -> s.length() > 2) // ← Predicate<string> 的 lambda 实现
.map(String::toUpperCase) // ← Function<string string> 的方法引用
.forEach(System.out::println); // ← Consumer<string> 的方法引用</string></string></string>
这三处看似简洁的写法，背后分别触发了 Predicate.test()、Function.apply()、Consumer.accept() 的调用。
Supplier 是流的源头，Consumer 是流的终点
流的生命周期两端也由函数式接口支撑：
- 创建无限流常用
Stream.generate(Supplier：Supplier 的) get()方法按需生成元素，比如Stream.generate(Math::random) - 收集结果常用
collect(Collectors.toMap(k -> k.name, v -> v.age))：其中 keyMapper 和 valueMapper 都是Function，而下游的Collector内部也封装了Supplier（容器工厂）、BiConsumer（累加器）、BinaryOperator（合并器） - 自定义终端操作时，
forEach、peek等都依赖Consumer实现“只用不返回”的语义
避坑关键：接口类型决定行为边界
选错函数式接口会导致编译失败或语义错误：
- 想转换类型却用了
Consumer→ 编译报错（它不返回值） - 在
filter里写了s -> { System.out.println(s); return true; }→ 语法合法，但属于Consumer+return混用，可读性差，应拆成peek+filter - 误把
Function当Supplier传给generate→ 编译不通过（前者要入参，后者不要）
所以写 Stream 代码前，先确认你要做的动作属于哪一类语义：判断？转换？消费？生成？再挑对应接口，就自然顺了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
