函数式接口必须有且仅有一个抽象方法,需显式标注@FunctionalInterface以确保设计意图;应复用Java标准库接口,仅在语义不匹配时自定义,命名需明确,保持行为契约的开放性与泛型扩展能力。

要在接口设计中让 Lambda 表达式能直接使用,核心是把接口定义成函数式接口——即只暴露一个抽象方法,其他全是默认方法、静态方法或 Object 的重写方法。
明确声明 @FunctionalInterface 注解
加这个注解不是可选的,而是设计意图的强制表达。它让编译器帮你检查:一旦不小心多加了一个抽象方法,立刻报错,避免后期调用 Lambda 时类型不匹配。
- 接口必须有且仅有一个抽象方法(不能是重写 Object 的方法,比如 toString())
- 可以任意数量的 default 方法和 static 方法,它们不破坏函数式语义
- 即使不加注解,只要满足“单抽象方法”条件,Lambda 也能用;但加了才体现设计自觉性
参数与返回值要清晰、通用
函数式接口的抽象方法签名,决定了 Lambda 能怎么写、适合解决哪类问题。设计时优先考虑复用性,而不是绑定具体业务。
Java项目代码review工具。分析Git变更+完整调用链路上下文,推断业务需求,进行多维度评分和分类汇总,生成完整PRD文档。包含细粒度Java代码审查清单(Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 比如传一个 T 类型参数、返回 boolean,就适配
Predicate<T>场景(如过滤) - 如果需要转换数据,方法应接受一个输入、返回一个输出,对应
Function<T, R> - 避免把参数写死成
String或int,用泛型保持扩展空间
配合标准库接口,减少自定义
Java 8+ 已提供一整套常用函数式接口(Runnable、Consumer、Supplier、Predicate、Function 等),绝大多数场景无需重复造轮子。
立即学习“Java免费学习笔记(深入)”;
- 例如想定义“执行某操作并打印日志”,直接用
Consumer<String>就行,不用另建LoggerAction - 只有当标准接口无法准确表达语义时(比如“计算两个日期之间的工作日天数”),再考虑自定义
- 自定义时命名要有意义,比如
DayCalculator比MyFunc更利于团队理解
预留扩展能力,不锁死实现细节
函数式接口本质是行为契约,不是具体逻辑。设计时别在接口里埋实现倾向,比如加字段、强制继承某个类,或要求必须用某种算法。
- 抽象方法体为空,只定义“做什么”,不规定“怎么做”
- default 方法可提供通用辅助逻辑(如空值检查、日志包装),但不要替代主抽象方法的职责
- 允许使用者用 Lambda、方法引用、甚至匿名内部类来实现,保持开放性

















