函数式接口本质是“有且仅有一个抽象方法”的行为契约，用于适配Lambda、方法引用和Stream；面试重在理解其设计意图与场景联动，而非死记接口定义。
Java 函数式接口是大厂面试中高频考点，核心不在背定义，而在理解“为什么需要它”和“怎么用对场景”。面试官真正想考察的是你对 Lambda、方法引用、Stream 与函数式接口之间联动逻辑的掌握程度，而不是能否默写出 Function 的四个抽象方法。
函数式接口的本质：不是语法糖，是契约
一个接口只要**有且仅有一个抽象方法**（default 和 static 方法不算），它就是函数式接口——@FunctionalInterface 注解只是编译期校验工具，不是必要条件。关键在于这个“唯一抽象方法”定义了行为契约，比如：
-
Runnable.run()：无入参、无返回，代表“可执行动作” -
Supplier.get()：无入参、有返回，代表“数据供给者” -
Predicate.test()：有入参、返回 boolean，代表“判断逻辑”
面试时如果被问“为什么 Runnable 是函数式接口”，答“因为只有一个 run 方法”只是基础分；若能补一句“所以它天然适配 Lambda 表达式，让线程启动从匿名内部类简化为 () -> System.out.println("ok")”，才算踩中设计意图。
别只背四大接口，重点看组合与推导
大厂常考接口间的转换与组合能力，比如：
立即学习“Java免费学习笔记（深入）”；
-
Function<t></t>的andThen()和compose()区别：前者是“先 this 再参数”，后者是“先参数再 this” -
Predicate的and()/or()/negate()可链式构建复杂条件，比手写 if-else 更具表达力 - 自定义函数式接口时，注意泛型约束是否合理——例如写一个
TriFunction<t></t>，就要确认是否真需三参数，还是能用对象封装降维
现场写代码题常让用 Function + BiFunction 实现字符串处理链，考察是否理解类型推导（如 Function<string integer> f = s -> s.length();</string> 不必写完整泛型）。
和 Stream 配合时，接口选择决定代码可读性
Stream 操作中传入的 Lambda 实际都绑定到某个函数式接口，选错会导致语义混乱：
-
filter()必须用Predicate（返回 boolean），写成Function编译不过 -
map()要Function，但若返回 null，后续可能 NPE——这时该考虑用Optional或改用flatMap()配合Supplier -
collect()的三个参数分别对应Supplier、BiConsumer、BiConsumer，记不住就联想“谁来造容器、谁来塞元素、谁来合并”
面试写一段统计单词频次的代码，有人用 forEach 配 Consumer 手动累加，有人用 collect(Collectors.groupingBy(...))，后者更优不仅因简洁，更因它隐含了并发安全的设计假设（底层用 ConcurrentHashMap）。
避坑：常见误解与边界情况
这些点一问一个准，容易暴露知识盲区：
- 接口里有多个 default 方法？不影响它是函数式接口（只要抽象方法仍唯一）
- Lambda 表达式捕获局部变量，该变量必须是“事实上 final”——不是语法上加 final，而是不能在 Lambda 外再赋值
-
void方法引用（如System.out::println）只能用于Consumer等返回 void 的接口，不能塞进Function - 方法引用
String::new对应的是Function（一参构造）、Supplier（无参）、甚至BiFunction（两参），具体类型由上下文决定
不复杂但容易忽略。
