@FunctionalInterface不是Lambda使用的前提，而是编译期对单抽象方法接口的声明式校验；Lambda能否使用取决于目标类型是否具有唯一抽象方法签名，与该注解无关。
@FunctionalInterface 不是使用 Lambda 的前提，而是对已有接口的“声明式校验”——它只在编译期起作用，不参与运行，也不影响 Lambda 能否写成。
为什么加了 @FunctionalInterface 编译反而报错？
常见错误现象：Unexpected @FunctionalInterface annotation 或 Multiple non-overriding abstract methods。说明你标错接口了：要么接口里有超过一个未实现的抽象方法（比如漏写了 default 或 static），要么继承了其他接口却没处理方法冲突。
使用场景：仅用于你**自己定义的、明确只供 Lambda 实现的接口**，比如封装回调、策略或事件处理器。
- 必须且只能有一个抽象方法（
Object继承的方法如toString()不算） - 允许有任意数量的
default方法和static方法 - 如果接口继承自另一个函数式接口，要确保抽象方法签名一致（否则会变成两个抽象方法）
Lambda 能写的真正前提是什么？
不是注解，而是类型系统能否推导出唯一抽象方法签名。只要目标类型是“只有一个抽象方法的接口”，不管有没有 @FunctionalInterface，Lambda 都合法。
立即学习“Java免费学习笔记（深入）”；
参数差异：Lambda 形参个数/类型必须与该抽象方法完全匹配；返回值也需兼容（协变允许子类型）。
性能 / 兼容性影响：无。Lambda 编译后生成私有静态方法 + 内部类（或 invokedynamic），和是否加注解无关。
- 下面三个写法都合法，哪怕
Runnable没加@FunctionalInterface（它其实加了，但不是关键）：Runnable r1 = () -> System.out.println("ok"); - 这个接口没加注解，照样能用 Lambda：
interface Calc { int apply(int a, int b); }Calc add = (a, b) -> a + b;
- 但如果写成：
interface Bad { void run(); void stop(); }——加了@FunctionalInterface会编译失败，不加也能编译，但无法用 Lambda 实例化
什么时候必须加 @FunctionalInterface？
不是为了“让 Lambda 能用”，而是为了防止后续误改破坏函数式契约。比如团队协作中有人给你的策略接口新增了一个抽象方法，没加注解就悄无声息，结果所有调用处的 Lambda 全挂了。
容易踩的坑：@FunctionalInterface 对泛型接口无效校验（JDK 8 bug 级限制），比如：
interface Mapper<T> { T map(String s); T fallback(); }看起来像两个方法，但 fallback() 是重载还是重写？编译器可能放行，但实际无法用 Lambda。
- 只对明确设计为单抽象方法的接口加，别给
Comparator这种 JDK 已标注的再加一遍 - 不要加在类、抽象类、枚举或注解上（编译直接报错）
- 如果接口方法依赖类型变量（如
<t> T get()</t>），确保擦除后仍唯一
最容易被忽略的是：Lambda 是否可用，完全取决于上下文类型是否可推导出单一抽象方法签名——@FunctionalInterface 只是帮你提前发现“这个接口已经不适合 Lambda 了”。它不参与类型检查，也不影响字节码。
