@functionalinterface 用于确保接口有且仅有一个抽象方法，支持lambda等函数式特性，提升可读性与协作效率，防止误加方法，并兼容object方法、默认方法和静态方法。
@FunctionalInterface 注解本身不处理变量，它只用于规范接口定义——确保一个接口有且仅有一个抽象方法，从而能安全地被 Lambda、方法引用等函数式编程特性消费。在团队协作中，它的价值在于统一认知、提前拦截错误、提升可读性，而不是直接参与变量操作。
明确接口设计意图
加 @FunctionalInterface 不是“多此一举”，而是向所有协作者声明：“这个接口就是用来做单一行为抽象的”。比如处理用户输入的清洗逻辑：
- 定义 InputProcessor 接口时加上该注解，就排除了后续误加 validate()、format() 等多个抽象方法的可能性
- 成员看到接口带此注解，会自然联想到它适合写成
input -> input.trim().toLowerCase()这类简洁表达 - 新人阅读代码时，无需翻源码就能判断该接口是否支持 Lambda 赋值
配合 IDE 和编译器做静态防护
团队统一开启编译检查后，任何违反函数式接口规则的修改都会立刻暴露：
- 新增抽象方法？编译失败，错误提示清晰指出 “Multiple non-overriding abstract methods found”
- 误删唯一抽象方法？同样报错，强制补全或重新评估接口用途
- 默认方法和静态方法可自由添加，不影响注解有效性（如增加通用日志包装 default logThenApply(...)）
优先复用标准函数式接口，减少自定义
团队应建立接口使用规范，避免为简单场景重复造轮子：
- 参数一个、返回一个 → 直接用 Function
，而非新建 StringToIntConverter - 需要两个入参（如旧值+新值）→ 用 BiFunction
- 仅执行无返回 → 用 Consumer
或 BiConsumer - 确需语义化命名（如 PaymentHandler）再自定义，且必须加 @FunctionalInterface 并附 Javadoc 说明用途
兼容 Object 方法与默认行为
团队成员常误以为 equals()、hashCode() 等会破坏函数式接口性质，其实不会：
- 接口中显式声明
boolean equals(Object o);不计入抽象方法计数 - 可放心添加 default 方法封装公共逻辑（如空值校验、异常转换），增强复用性
- 静态工具方法（如 fromConfig() 构造实例）也完全允许，不干扰函数式语义
