@FunctionalInterface 注解仅在编译期强制校验接口有且仅有一个抽象方法，排除default、static及重写Object的方法；不加也能用Lambda，但加了可防误改并明确函数式契约意图。
@FunctionalInterface 注解本身不参与运行时类型检查，它的强类型约束完全发生在编译期，本质是编译器对“接口是否满足函数式接口定义”的一次静态断言。
编译期强制校验：只允许一个抽象方法
当你在接口上写 @FunctionalInterface，javac 就会立即执行一项硬性检查：该接口中声明的抽象方法数量必须严格等于 1。不是“建议”，而是“不满足就报错、中断编译”。
- 有 0 个抽象方法 → 报错：“No abstract method found”
- 有 2 个或以上抽象方法 → 报错：“Multiple non-overriding abstract methods found”
- 仅 1 个抽象方法 → 编译通过
哪些方法不计入抽象方法计数
编译器在统计抽象方法时，会智能排除三类方法，它们不破坏函数式接口的“单抽象方法”本质：
- 默认方法（default 修饰）—— 属于已有实现，不算抽象
- 静态方法（static 修饰）—— 不属于实例契约，不参与 SAM 计数
- 重写自 Object 的方法（如
toString()、equals(Object)、hashCode()）—— 接口实现类天然继承这些行为，不视为新增抽象能力
与 Java 强类型机制的协同逻辑
这个检查不是孤立的，它嵌入在 Java 整体的编译期强类型体系中：
立即学习“Java免费学习笔记（深入）”；
- 和泛型检查一样，它发生在类型擦除之前，依赖完整的源码结构分析
- 和变量赋值检查一样，它不生成警告，而是直接拒绝生成 .class 文件
- 它确保后续使用 Lambda 表达式时，目标类型具备明确、唯一的抽象方法签名，从而让编译器能安全推导出参数类型和返回类型
不加注解也能用 Lambda？那为什么还要它？
是的，只要接口客观上只有一个抽象方法，即使没加 @FunctionalInterface，Lambda 依然可用。但加了它，就激活了两层保障：
- 防止未来误增抽象方法：别人或你自己后续修改接口时，多加一个
void cancel();就立刻触发编译失败，而不是等运行时才发现 Lambda 绑定异常 - 明确设计意图：告诉所有协作者，这不是普通接口，而是为函数式编程而生的契约类型，提升代码可读性与维护确定性
