函数式接口本质是封装单一行为契约，需用@functionalinterface显式标记、严格限定一个抽象方法，并通过泛型和default/static方法强化语义；其设计起点是“做什么”，而非“是什么”。

Java 中接口利用“只含一个抽象方法”这一特性声明为函数式契约，关键在于**明确行为意图、严格约束抽象方法数量、配合注解与语言机制形成可验证的契约**。这不是语法便利，而是设计层面的行为建模。

用 @FunctionalInterface 显式标记契约意图

加 @FunctionalInterface 注解不是为了启用 Lambda，而是向编译器和团队声明：“这个接口代表一种单一行为，不可随意扩展”。一旦加上，编译器会强制检查——如果误增第二个抽象方法，立即报错，避免契约被破坏。

• 不加注解也能用 Lambda，但失去编译期防护，容易在后期维护中意外污染接口语义
• 它和 @Override 类似，是沟通工具：告诉所有人“这里只许定义一种动作”
• 哪怕接口只含一个抽象方法，也建议始终标注，这是契约意识的体现

把“做什么”而不是“是什么”作为设计起点

函数式接口的本质是封装可变行为，不是描述数据结构。设计时先想清楚：这个接口要表达哪一类动作？比如“判断”“转换”“消费”“供给”，然后据此命名并定义唯一方法。

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• 正确示例：Predicate<t></t>（判断）、Function<t></t>（转换）、Consumer<t></t>（消费）——每个都对应一种清晰的动作语义
• 错误倾向：在同一个接口里塞 validate() 和 format()，这已违背单一行为契约
• 泛型参数应服务于行为逻辑，例如 UnaryOperator<t></t> 隐含输入输出同类型，强化了“一元变换”的契约感

用 default 和 static 方法补全契约能力，而非增加抽象职责

函数式接口允许任意 default 和 static 方法，它们不是行为变体，而是对主抽象方法的增强或组合支持，不破坏“单一入口”原则。

• Comparator.reversed() 是 default 方法，它不新增比较逻辑，而是基于已有 compare() 返回新实例
• Function.identity() 是 static 工厂方法，提供常用实现，不改变 apply() 的契约含义
• 重写 equals() 或 toString() 属于 Object 协议，编译器自动忽略，不影响函数式判定

让 Lambda 和方法引用自然成为实现方式

当接口真正只暴露一个抽象方法时，Lambda 表达式才能无歧义地匹配——编译器不需要猜你要实现哪个方法，直接绑定到那个唯一入口。

• 写 list.removeIf(x -> x ，背后就是 <code>Predicate.test() 的调用，语义直白
• 用 String::length 赋值给 Function<string integer></string>，是因为两者签名完全对齐，无需额外适配
• 若接口有两个抽象方法，Lambda 就无法确定目标，只能退回到匿名类，失去简洁性与函数式表达力

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南