函数式接口必须有且仅有一个抽象方法，需显式标注@FunctionalInterface以确保设计意图；应复用Java标准库接口，仅在语义不匹配时自定义，命名需明确，保持行为契约的开放性与泛型扩展能力。
要在接口设计中让 Lambda 表达式能直接使用，核心是把接口定义成函数式接口——即只暴露一个抽象方法，其他全是默认方法、静态方法或 Object 的重写方法。
明确声明 @FunctionalInterface 注解
加这个注解不是可选的，而是设计意图的强制表达。它让编译器帮你检查：一旦不小心多加了一个抽象方法，立刻报错，避免后期调用 Lambda 时类型不匹配。
- 接口必须有且仅有一个抽象方法（不能是重写 Object 的方法，比如 toString()）
- 可以任意数量的 default 方法和 static 方法，它们不破坏函数式语义
- 即使不加注解，只要满足“单抽象方法”条件，Lambda 也能用；但加了才体现设计自觉性
参数与返回值要清晰、通用
函数式接口的抽象方法签名，决定了 Lambda 能怎么写、适合解决哪类问题。设计时优先考虑复用性，而不是绑定具体业务。
deep-java-review
下载
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、方法引用、甚至匿名内部类来实现，保持开放性
