函数式接口命名应采用大驼峰风格，优先使用动词或形容词（如predicate、retryable），避免名词（如userhandler）及冗余后缀（如functional）；可结合“名词+动词/形容词”表达领域行为（如paymentretryable），并必须显式添加@functionalinterface注解。
函数式接口命名要兼顾语义清晰、风格统一和团队可读性，不是单纯套用驼峰规则就能过关。核心是让接口名本身能“说话”，一眼看出它封装的是什么行为。
接口名必须用大驼峰，且优先选用动词或形容词
这是企业级项目最普遍的约定。因为函数式接口本质是行为契约，不是实体建模——所以不用名词（如 UserProcessor），而用能表达动作或能力的词：
- 推荐： Runnable、Comparable、Serializable、Callable、Predicate、Consumer
- 自定义时也照此逻辑： Validatable（可校验）、Transformable（可转换）、Retryable（可重试）、Filterable（可过滤）
- 避免： UserHandler、DataConverter（这类偏向具体实现，易与普通类/抽象类混淆）
不强行加 “Functional” 或 “Lambda” 后缀
这类后缀冗余且违背语义化原则。函数式接口的“函数式”属性由 @FunctionalInterface 注解和单一抽象方法保证，不是靠名字喊出来的：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- ❌ UserServiceFunctional、OrderValidatorLambda
- ✅ UserService（如果它真只有一个抽象方法且符合函数式语义）或更准确的 OrderValidatable
业务场景下可采用 “名词 + 动词/形容词” 组合结构
当标准动词/形容词不足以表达领域意图时，Spring 等主流框架已验证这种模式可行且易懂：
- Spring 示例：ApplicationContextAware、MessageSourceResolvable、TargetClassAware
- 业务自定义：PaymentRetryable、InventoryCheckable、NotificationSendable
- 关键点：名词部分明确上下文（Payment/Inventory/Notification），动词部分说明能力（Retryable/Checkable/Sendable），整体构成完整行为契约
必须显式添加 @FunctionalInterface 注解
这是企业规范的硬性要求，不是可选项。它起到三重作用：
- 向团队声明：“这个接口设计为函数式用途，别乱加第二个抽象方法”
- 触发编译器检查，一旦违反“唯一抽象方法”规则立即报错
- 在 IDE 和文档生成工具中形成明确标识，提升可发现性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
