函数式接口是lambda表达式的唯一合法宿主，必须有且仅有一个抽象方法（不计default/static方法），可含任意default和static方法；其类型由上下文目标类型决定，编译器据此匹配唯一抽象方法签名。
函数式接口是Lambda表达式的唯一合法“宿主”——它不是语法糖的装饰，而是Java类型系统为支持Lambda所设定的硬性契约。只有被@FunctionalInterface明确标注（或天然满足条件）的接口，才能用Lambda简洁实现；反之，试图对普通接口写Lambda，编译器会直接报错。
什么是函数式接口？关键就三条
一个接口要成为函数式接口，必须同时满足：
- 有且仅有一个抽象方法（不计
default和static方法） - 可以有任意多个
default方法（提供默认行为，不破坏函数式契约） - 可以有任意多个
static方法（工具方法，与实例无关）
例如java.util.function.Predicate<t></t>只定义了test(T)一个抽象方法，其余全是default组合方法（如and()、or()），所以它是标准函数式接口。
Lambda如何精准绑定到函数式接口
Lambda表达式本身没有类型，它的类型由**上下文目标类型**决定——而这个目标类型必须是函数式接口。编译器通过参数数量、类型、返回值三要素，自动匹配接口中唯一的抽象方法签名。
比如这行代码：
Predicate
左边声明类型是Predicate<string></string>（函数式接口），右边Lambdas -> ...就自动被认定为实现了它的test(String)方法。参数s类型由接口方法推导，无需显式写出。
为什么非要加@FunctionalInterface注解
这个注解不是必需的，但强烈建议加上——它起的是编译期防护作用：
- 若接口本意是函数式，却意外新增了一个抽象方法，加了注解就会编译失败，及时暴露设计错误
- 它向其他开发者明确传达：“此接口专为Lambda/方法引用设计，请勿随意添加抽象方法”
- 没加注解也不影响Lambda使用，只要逻辑上满足“单抽象方法”即可（如早期的
Runnable、Comparator）
常见误区：不是所有带一个方法的接口都能用Lambda
以下情况即使只有一个抽象方法，也不能安全用于Lambda：
- 该方法与
Object中的public方法同名同签名（如toString()、hashCode()、equals(Object)），因为这些方法会被视为继承自Object，不算接口自己的抽象方法 - 接口继承了多个父接口，导致实际抽象方法总数超过1个（哪怕子接口只声明0个）
- 用了泛型通配符或复杂类型推导，导致编译器无法唯一确定目标函数签名
简单说：能用Lambda的，一定是编译器能**无歧义地把Lambda体映射到某个且仅某个抽象方法**上的接口。
