函数式接口本质是编译期类型契约，仅允许一个抽象方法，使Lambda能明确绑定目标方法；它依赖@FunctionalInterface注解校验、invokedynamic指令动态链接，且必须有目标类型推断。
函数式接口本身没有“运行时魔法”，它的底层原理核心就两点：编译器约束 + JVM 链接机制。讲清楚不靠术语堆砌，而是抓住“为什么需要它”和“它到底干了什么”。
函数式接口的本质是类型契约
它不是新语法，而是一种编译期约定：只允许有一个抽象方法的接口。这个限制让编译器能明确知道——当写 (x) -> x * 2 这样的 Lambda 时，该把它绑定到哪个方法上。
- @FunctionalInterface 注解不是必需的，但加上后，编译器会强制检查：多一个抽象方法就报错，少一个也报错
- 默认方法（default）、静态方法（static）、甚至重写的 Object 方法（如 toString、equals）都不算抽象方法，不影响函数式接口身份
- Runnable、Comparable、ActionListener 这些老接口，只要满足“仅一个抽象方法”，天然就是函数式接口
Lambda 不是匿名内部类，但早期容易混淆
很多人说 Lambda 是匿名内部类的语法糖，这在语义上方便理解，但底层实现完全不同：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 匿名内部类编译后生成独立的
Outer$1.class文件，本质是真实类，有完整对象开销 - Lambda 编译后不生成独立 class 文件，而是通过 invokedynamic 指令，在运行时由 JVM 动态链接到一个“合成方法”（通常叫 lambda$xxx）
- 这个合成方法可能被放在原类里，也可能被委托给 java.lang.invoke.LambdaMetafactory，取决于逃逸分析和捕获变量情况
真正关键的是“目标类型推断”
Lambda 表达式本身没有类型，它必须被赋值给一个函数式接口类型的变量，或作为参数传给接受该接口的方法——这个接口就是它的“目标类型”。
立即学习“Java免费学习笔记（深入）”；
- 例如
Consumer<string> c = s -> System.out.println(s);</string>，左边的 Consumer告诉编译器：这个 Lambda 要实现 accept(String) 方法 - 如果上下文无法推断（比如直接写
s -> s.length()不赋值），编译会失败 - 这也解释了为什么不能把 Lambda 直接赋给 Object 或泛型未限定的类型
四大核心接口是设计模式的标准化封装
java.util.function 包里的 Predicate、Consumer、Function、Supplier 不是黑科技，而是把常见行为模式抽象成可复用的函数式接口：
- Predicate
：只做判断，返回 boolean → 适合 filter - Consumer
：只消费输入，不返回结果 → 适合 forEach - Function
：接收 T，输出 R → 适合 map - Supplier
：不接收输入，只产出 T → 适合延迟创建、工厂场景
