Java自定义函数式接口应将泛型声明在接口层级而非方法上，如Mapper，确保类型安全与SAM合规；需用@FunctionalInterface注解防护，并结合领域对象封装多参数，避免过度泛化。
Java 自定义函数式接口接收泛型参数，核心是把类型变量声明在 interface 层级，而不是方法上；抽象方法用这些泛型参数构建签名，Lambda 实现时由编译器自动推断具体类型，从而实现类型安全的通用逻辑。
泛型必须声明在接口上，不能只写在方法里
错误写法（方法级泛型）会导致接口不满足函数式接口要求，因为该方法不是 SAM（单一抽象方法）：
❌ 不推荐：interface BadExample { <T> T transform(Object input); }
正确写法是泛型参数直接挂在 interface 后，整个接口具备类型参数能力：
✅ 正确示例：@FunctionalInterface
interface Mapper<I, O> {
O apply(I input);
}
这样 Mapper
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
方法签名要体现业务意图，避免 Object 或泛化命名
泛型不是为了“能传任意类型”，而是为了在保持类型约束的前提下复用逻辑。方法名和参数应直指业务场景：
- ✅
Validator<order> orderCheck = o -> o.getStatus() == OrderStatus.VALID;</order> - ✅
Converter<jsonnode product> jsonToProduct = node -> new Product(node.get("id").asInt());</jsonnode> - ❌ 避免：
Function<object object> doWork = x -> {...};</object>—— 失去编译期检查，运行时才可能出错
结合领域对象封装多参数，别堆砌泛型变量
如果逻辑需要多个输入，不要定义 TriFunction<a b c r></a> 这类难维护的接口。更合理的方式是先建一个轻量领域对象，再用单泛型接口处理它：
@FunctionalInterface
interface RiskAssessment<T> {
AssessmentResult evaluate(T context);
}
// 使用时
RiskAssessment<OrderRiskContext> assessor = ctx -> {
if (ctx.getAmount().compareTo(HIGH_RISK_THRESHOLD) > 0) {
return AssessmentResult.HIGH;
}
return AssessmentResult.LOW;
};
OrderRiskContext 可以包含订单、用户、设备指纹等上下文字段，接口保持简洁，语义清晰，扩展也方便。
加 @FunctionalInterface 注解，防误改
这个注解本身不参与运行，但它是编译期守门员：一旦后续不小心加了第二个抽象方法，编译直接报错，避免隐性破坏函数式契约：
- 允许存在 default 方法、static 方法、equals/hashCode/toString
- 禁止新增未被重写的 public abstract 方法
- 哪怕只多一个抽象方法，也会提示 “not a functional interface”
