函数式接口是且仅有一个抽象方法的接口，Lambda通过参数和返回值匹配该方法；可含任意default、static及Object方法；@FunctionalInterface仅为校验注解。
函数式接口就是 Java 里「能用 Lambda 写实现」的接口，前提是它**有且仅有一个抽象方法**——不是“看起来像函数”，而是编译器能靠这个约束把 (x) -> x + 1 这种写法准确绑定到唯一方法上。
为什么必须只有一个抽象方法？
因为 Lambda 表达式不写方法名，只靠参数类型和返回值来匹配。如果接口有两个抽象方法（比如 doA() 和 doB()），JVM 就没法知道你写的 () -> System.out.println("hi") 到底想实现哪个。
- 编译器靠这个规则做类型推导，不是靠注解；
@FunctionalInterface只是“提醒+校验”，不加它也照样是函数式接口（只要满足 SAM） - 可以有任意个
default方法、static方法，甚至重写Object的方法（如toString()），都不影响它是函数式接口 - 常见误判：把
Runnable当成“无参无返回”专用接口就对了，但别以为Comparator不是函数式接口——它只有int compare(T o1, T o2)一个抽象方法，所以也是
Java 内置四大核心接口怎么选？
别背名字，看方法签名和使用意图：
-
Supplier<t></t>：无参 → 有返回，典型场景是“懒加载”或“造数据”，比如LocalDate::now、() -> new Random().nextInt() -
Consumer<t></t>：有参 → 无返回，适合“做了就完事”，比如System.out::println、s -> log.info("received: {}", s) -
Predicate<t></t>：有参 →boolean，专干判断，比如s -> s != null && !s.isBlank()，自带and()/or()链式组合 -
Function<t r></t>：有参 → 有返回（类型可变），专注“转换”，比如String::length、s -> s.trim().toLowerCase()，支持andThen()和compose()组合
注意：基本类型有特化版（IntSupplier、LongConsumer 等），避免装箱开销；两个参数用 BiFunction、BiPredicate；三个及以上参数就得自定义，标准库没提供。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
自定义函数式接口时最容易踩的坑
不是语法错，而是语义和复用性问题：
- 别为了“看起来高级”硬套
@FunctionalInterface——如果接口未来大概率要加第二个抽象方法（比如从“校验”扩展出“修复”），那就别标，否则改接口会直接 break 所有调用处 - 参数命名和泛型别太随意：
MyProcessor<x y></x>不如Transformer<in out></in>直观；方法名别叫handle()，优先用apply()/test()/get()这类通用动词，方便开发者直觉理解 - 默认方法别写副作用逻辑：比如在
andThen()里偷偷打印日志，会让使用者困惑——函数式接口强调“纯行为”，副作用该由Consumer显式承担
@FunctionalInterface
public interface TriFunction<T, U, V, R> {
R apply(T t, U u, V v);
}
// 使用示例
TriFunction<String, Integer, Boolean, String> formatter = (name, age, isStudent) ->
name + "(" + age + ")" + (isStudent ? "[S]" : "");
String result = formatter.apply("Alice", 22, true); // "Alice(22)[S]"
真正难的不是写出一个函数式接口，而是判断某个需求该不该用它——比如“回调通知”用 Consumer 没问题，但“需要返回状态码+错误信息”的场景，就该老老实实写普通接口，别硬塞进 Function<req resp></req> 里。
