函数式接口本质是将单一行为标准化为类型安全的契约，仅含一个抽象方法，需用@functionalinterface注解约束，配合泛型与业务命名实现自解释与复用。
函数式接口在面向对象设计中，本质是把“行为”变成可声明、可传递、可校验的契约，而不是写一堆零散的方法或继承体系。它不替代传统接口对能力的抽象，而是聚焦于**单一动作逻辑的标准化表达**——比如“判断”“转换”“执行”，让行为本身具备类型安全和复用性。
只保留一个抽象方法，明确行为意图
接口里必须且仅有一个未实现的抽象方法，这是编译器识别函数式接口的基础。这个方法名要直白反映业务动作，参数和返回值类型需稳定：
- 用 Predicate
表达“是否满足条件”，如 Predicate<order> isPayable = order -> order.getAmount().compareTo(BigDecimal.ZERO) > 0;</order> - 用 Function
表达“输入转输出”，如 Function<userentity uservo> toVO = u -> new UserVO(u.getId(), u.getName());</userentity> - 避免在同一个接口里塞多个行为，比如既做校验又做转换，那说明职责没拆清，该拆成两个接口。
用 @FunctionalInterface 强制约束与提示
加上这个注解不是可选项，是规范动作。它有两个实际作用：
- 编译期检查：一旦误加第二个抽象方法，立即报错，防止契约悄悄变质
- 语义提示：看到这个注解，团队成员立刻明白“这是个行为载体，该用 Lambda 或方法引用，不是去实现类里重写一堆逻辑”
- 别只写接口不加注解，也别给非函数式接口乱加——比如含多个抽象方法的业务能力接口（如 PaymentProcessor），就不该加。
default 和 static 方法只做辅助，不模糊主契约
默认方法和静态方法可以有，但必须服务于那个唯一的抽象方法，不能喧宾夺主：
-
default 方法适合通用组合逻辑，比如
and()、or()在 Predicate 中，或andThen()在 Function 中 -
static 方法适合无状态工具，比如
StringFormatter.trimAndUpper()，调用方直接通过接口名使用，不依赖实例 - 禁止在 default 方法里访问实现类私有字段，也不该封装复杂业务流程——那是实现类或策略对象的事。
配合泛型与命名，让契约自解释
函数式接口不是技术玩具，是业务语言的一部分。命名和泛型要体现真实场景：
- 接口名用动名词，如 OrderValidator、PhoneMasker，而不是
MyFunc或Handler - 泛型参数要有业务含义，比如
Function<paymentrequest paymentresult></paymentrequest>比Function<object object></object>更清晰、更安全 - 如果某类行为在多个模块高频出现（如空值处理、时间格式化），就把它抽成公共函数式接口，统一放在
contract包下，新同事一看就知道“这事有标准做法”。
不复杂但容易忽略：契约的价值不在定义得多漂亮，而在是否被一致使用。一个团队若约定所有字段映射走 Function，所有校验走 Predicate，那代码结构自然收敛，Merge 冲突少了，新人读起来也顺。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
