@FunctionalInterface 能在编译期强制校验函数式接口的单抽象方法规则，防止误增抽象方法导致Lambda失效；允许default、static及Object重写方法；提升协作清晰度与IDE支持，零运行开销。
因为 @FunctionalInterface 能在编译阶段就拦住接口设计的常见失误，让 Lambda 表达式不会“突然失效”。
它强制守住函数式接口的核心规则
一个接口要能接住 Lambda，必须有且仅有一个抽象方法——这是硬性前提。@FunctionalInterface 不是摆设，它会让编译器盯死这条线：
- 如果你加了第二个抽象方法，编译直接失败，错误提示明确指向“不是函数式接口”
- default 方法和 static 方法完全不受影响，可以照常添加
- 重写 Object 的 equals、hashCode、toString 等方法，也不算新增抽象方法
它提前暴露“看似能用、实则危险”的误操作
不加注解时，接口可能侥幸满足单抽象方法条件，但一旦后续有人无意中加了个新抽象方法，代码立刻崩在 Lambda 赋值处，而错误位置和原因却很隐蔽：
- 比如你写了 Broken b = () -> System.out.println("oops");，报错信息只说“目标类型不是函数式接口”，却不告诉你问题出在接口定义里
- 加上 @FunctionalInterface 后，新增抽象方法的那一刻就报错，问题定位快、修复成本低
它让协作意图一目了然
在团队项目中，光靠“约定俗成”不可靠。这个注解相当于在接口头上贴了张标签：
- 告诉其他开发者：“这个接口专为 Lambda 或方法引用设计，请勿随意扩展抽象行为”
- 生成的 API 文档会自动标注该接口为函数式接口，提升可读性
- IDE 也能据此提供更精准的代码提示和重构支持
它不增加运行负担，纯属开发期保障
@FunctionalInterface 是编译期注解，不参与字节码执行，也不影响性能：
- 没加它，只要接口逻辑上只有一个抽象方法（如早期的 Runnable），Lambda 依然能用
- 但加了它，就能把“人肉检查”变成“机器校验”，把潜在风险锁死在编码阶段
- 它不是语法必需，却是工程规范的重要一环
