Java函数式接口是编译器强制约束的单抽象方法（SAM）接口，@FunctionalInterface为可选但推荐的显式标注；Lambda类型由目标接口上下文推导，须严格匹配参数与返回值签名。
Java 中的函数式接口不是语法糖，而是编译器强制约束的接口类型：必须有且仅有一个抽象方法（@FunctionalInterface 可显式声明并校验）。
如何识别一个接口是否为函数式接口
关键看它是否满足「单抽象方法」（SAM）规则，和是否被 @FunctionalInterface 标注 —— 后者不是必需，但强烈建议加，否则编译器不会报错，直到你尝试用 Lambda 赋值时才暴露问题。
-
Runnable、Comparator、Predicate、Function都是 JDK 自带的函数式接口 - 含多个抽象方法的接口（如自定义接口里写了两个
void doA()和int doB()），即使没加@FunctionalInterface，也不能用于 Lambda 表达式 - 默认方法（
default）和静态方法不破坏函数式接口性质；Object的公共方法（如toString()）也不算抽象方法
Lambda 表达式与函数式接口的绑定规则
Lambda 本身没有类型，它的类型由上下文中的目标函数式接口决定。编译器靠参数数量、类型、返回值反推匹配哪个接口。
- 写
() -> System.out.println("hi")，只有在赋值给Runnable或其他无参无返回接口时才合法 -
s -> s.length() > 0可匹配Predicate，但不能赋给Function（虽然语义相似，但接口签名不同） - 参数类型可省略（类型推导），但一旦省略，所有参数都得省；不能只写
(String s, t) -> ...——t类型缺失会编译失败
常见误用：把非函数式接口强行当 Lambda 使用
最典型的错误是忽略继承关系或重载导致的歧义。例如：
interface BadExample {
void run();
void stop(); // 第二个抽象方法 → 不是函数式接口
}
此时写 BadExample e = () -> {}; 会编译报错：BadExample is not a functional interface。更隐蔽的是：
- 某个类实现了多个函数式接口（如同时实现
Runnable和Supplier），传入 Lambda 时可能因重载解析失败而报错 - 泛型擦除后签名冲突：比如
Consumer和Consumer在字节码中都是Consumer，若方法重载仅靠泛型区分，Lambda 传参会编译失败 - 用
new Thread(() -> {...})没问题，但换成new Thread((Runnable)() -> {...})就多余 —— 编译器已能推导，强转反而可能掩盖类型不匹配
何时该自己定义函数式接口
当标准库的 Function、BiFunction、UnaryOperator 等无法准确表达业务语义时，定义带名称的接口比裸 Lambda 更利于维护。
- 命名即契约：比如
OrderValidator比Predicate更明确意图 - 便于添加 JavaDoc 和默认行为（如空检查、日志埋点）
- 避免过度泛型：不要为了“通用”而定义
TriFunction，JDK 8 没提供不代表你一定要补全；先用BiFunction>或封装对象，比自造轮子更稳妥
真正容易被忽略的是：Lambda 表达式捕获变量时，引用的对象必须是「实际上的 fina
++i，编译器就拒绝绑定 —— 这和函数式接口无关，但常和它一起出问题。
