函数式接口是类型契约，lambda是运行时动态实现，匿名内部类是编译期生成的静态类；三者各司其职：接口定义能力边界，后两者为不同实现方式，底层机制迥异。
直接说结论：函数式接口是“类型契约”，Lambda 是“动态实现”，匿名内部类是“静态类文件”。三者不是层层替代的关系，而是各司其职——接口定义能力边界，Lambda 和匿名内部类是两种不同的实现方式，底层机制完全不同。
函数式接口：不是语法糖，是编译器强制约定的契约
它只有一个抽象方法（比如 Runnable.run()、Comparator.compare()），加上 @FunctionalInterface 注解只是提醒你别写错，不加也不影响功能。关键点在于：
- JVM 不关心这个注解，但 javac 编译器会检查：一旦接口里出现第二个抽象方法，用 Lambda 就会报错
- Lambda 表达式只能赋值给函数式接口类型变量，不是因为它“长得像”，而是编译器在字节码层面做了类型匹配校验
- 它本身不生成任何代码，也不参与运行，只在编译期起约束作用
Lambda 表达式：运行时才“现身”的轻量实现
它看起来像匿名内部类的简化写法，但根本不是一回事。真正执行时，JVM 才动手干活：
- 编译后没有
.class文件，只有字节码里的invokedynamic指令，相当于留了个“待激活的钩子” - 第一次调用时，JVM 调用
LambdaMetafactory，用 ASM 动态生成一个实现了该函数式接口的类，并加载到内存 -
this指向外层类实例，不能定义自己的字段或方法；捕获的局部变量是“闭包引用”，不是复制一份字段
匿名内部类：编译期就落地的实打实类
它不是语法糖，而是一个真实存在的类，只不过名字由编译器代劳：
- 编译完立刻生成
Outer$1.class这样的独立文件，可以用javap反编译看到完整构造器、字段（如val$xxx）、方法字节码 -
this指向自己这个新对象，可以定义私有字段、额外方法、甚至重写父类同名方法 - 局部变量捕获靠“复制”，所以要求
final或 effectively final —— 否则副本和原始值可能不一致
怎么选？看三个实际信号
不用死记硬背区别，遇到具体场景，按这三点判断：
- 要实现的接口是不是只有一个抽象方法？不是 → 只能用匿名内部类（或普通类）
- 逻辑里要不要定义自己的状态（比如计数器、缓存 map）？要 → 匿名内部类更合适
- 这段逻辑会不会被高频创建（比如 Stream 处理百万元素）？会 → Lambda 更省内存，避免类加载压力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
