Java函数式接口核心四型是Predicate、Consumer、Supplier和Function；Function不可或缺，因其支持T→R转换，支撑map等链式操作闭环。
Predicate、Consumer、Supplier 不是“核心四型”——Java 里没有官方定义的“函数式接口核心四型”，只有 Predicate、Consumer、Supplier 和 Function 这四个最常用、JDK 自带的函数式接口。漏掉 Function，就等于没摸到函数式编程的开关。
为什么必须是 Function 才算齐套
这四个接口覆盖了函数式编程中最基础的输入输出组合：
-
Predicate<T>：输入一个T，返回boolean（比如list.stream().filter(x -> x > 0)） -
Consumer<T>：输入一个T，不返回值（比如list.forEach(System.out::println)） -
Supplier<T>：不输入，返回一个T（比如Optional.ofNullable(s).orElseGet(() -> "default")） -
Function<T, R>：输入T，输出R（比如list.stream().map(String::length)）
少任何一个，链式操作（尤其是 map / filter / flatMap 的组合）就会卡住。有人硬凑 BiPredicate 或 UnaryOperator 替代，结果发现它们只是特化版，不能替代 Function 的泛型灵活性。
写自定义函数式接口时，为什么 @FunctionalInterface 不是可选项
不加 @FunctionalInterface 不报错，但会埋两个坑：
立即学习“Java免费学习笔记（深入）”；
- 别人无法一眼识别这是设计为 Lambda 使用的接口，容易误加第二个抽象方法
- 编译器不会帮你检查是否真只有一个抽象方法——比如不小心重写了
Object.toString()的默认签名，又加了个test()，表面看像Predicate，实际已失效
正确姿势：
@FunctionalInterface
interface Validator<T> {
boolean validate(T t);
// 别写 default toString() 或其他 abstract 方法
}
用错泛型参数顺序，Stream 操作直接编译失败
Function 和 BiFunction 的参数顺序极易搞反：
-
Function<String, Integer>是 “从 String 转 Integer”，不是反过来 -
BiFunction<String, Integer, Boolean>是 (String, Integer) → Boolean，第一个类型对应第一个参数 - 写成
Function<Integer, String>却传str -> str.length()，编译器报incompatible types: java.lang.String cannot be converted to java.lang.Integer
常见错误现场：
// ❌ 错：map 期待 T→R，但这里返回的是 int，而 list 是 List<String> list.stream().map(s -> s.length()).collect(...); // ✅ 对：s.length() 是 int，所以 map 类型是 Function<String, Integer>
Supplier 的 get() 被多次调用，副作用可能失控
Supplier 看似安全，但一旦内部有状态或 IO，重复调用就出问题：
- 比如
Supplier<Connection> conn = () -> dataSource.getConnection()，每次get()都新建连接，却没关 - 再比如
Supplier<Long> now = System::currentTimeMillis，两次get()返回不同值，在Optional.orElseGet()里看似无害，但若逻辑依赖“同一时刻”，就隐性破防
原则：把 Supplier 当作“懒加载表达式”，而不是“缓存代理”。需要复用结果，就先 val = supplier.get() 存起来，别反复调。
真正难的不是记住这四个接口长啥样，而是判断某段逻辑该用哪个——尤其在嵌套 flatMap 或组合 andThen 时，类型推导一崩，编译器报错信息里满屏 cannot infer type arguments，这时候得倒回去看输入输出流是否闭环，而不是硬猜。
