Java函数式接口规范命名与设计的核心是语义清晰、语法合规、可维护性强：命名用动名词如StringConverter，抽象方法限1–2参数且返回类型具体，必须加@FunctionalInterface注解强制校验，严格遵循单抽象方法规则。
Java 中规范函数式接口的命名与设计，核心是兼顾语义清晰、语法合规和工程可维护性。它不是单纯写个带 @FunctionalInterface 的接口，而是围绕“行为抽象”这一本质，从命名意图、方法契约、结构约束三方面系统构建。
命名要体现行为意图，不堆砌名词
函数式接口不是实体类，它的名字应反映“能做什么”，而不是“是什么”。优先使用动名词短语或功能化描述，避免泛泛的 XXXHandler、XXXProcessor 等模糊后缀。
- 推荐写法：`StringConverter`（明确转换行为）、`UserValidator`（强调校验动作）、`RetryPolicy`（表达策略语义）
- 慎用写法：`UserService`（这是业务服务接口，非函数式）、`DataOp`（缩写无意义）、`IFunction`（过度抽象，失去上下文）
- 接口名首字母大写，遵循驼峰命名；不加
I前缀（Java 社区已弃用该习惯，Runnable、Predicate等 JDK 接口均无I）
抽象方法设计必须简洁、确定、可推断
这个方法就是 Lambda 的“签名模板”，它的定义直接决定调用端是否写得自然、类型是否能正确推导。
- 参数尽量控制在 1–2 个，类型用基础类型或常用泛型（如
T、String、Integer），避免嵌套包装类或自定义 DTO - 返回值类型必须具体，不建议用
Object或未约束泛型（如T无上界），否则 Lambda 内易触发编译错误或隐式装箱问题 - 方法名用通用动词：`apply`（转换）、`test`（判断）、`get`（获取）、`accept`（消费）、`convert`、`validate`、`retry` 等，保持与 JDK 函数式接口风格一致
结构上严格满足函数式接口定义，并主动防护
光“实际只有一个抽象方法”不够，必须通过语言机制固化规范，防止后续误改引入歧义。
立即学习“Java免费学习笔记（深入）”；
- 必须添加
@FunctionalInterface注解——这不是装饰，是编译期强制检查，一旦有人新增抽象方法，立即报错 - 允许有
default方法（提供默认逻辑）和static方法（工具能力），但它们不能替代抽象方法的核心契约 - 重写
Object的equals、toString等方法不破坏函数式性质，但一般无需显式声明，除非有特殊语义 - 注意继承关系：若接口 extends 另一个接口，父接口的抽象方法会计入总数；例如
extends Runnable后再定义一个方法，就违反了单抽象方法规则
结合典型场景选对抽象粒度
函数式接口的价值在于复用和组合，设计时要考虑它是否容易被 Lambda、方法引用或其它函数式接口组装使用。
- 单一职责：一个接口只抽象一类行为。例如区分 `Predicate
`（判断是否有效）和 `Function `（提取用户名），不要合并成一个“万能用户处理器” - 支持泛型但不过度参数化：`BiFunction
` 合理，但 ` ` 就丧失可读性与实用性 - 预留扩展性：可通过 default 方法补充常见变体（如 `andThen`、`negate`），但主抽象方法保持稳定不变
