Java函数式接口必须有且仅有一个抽象方法，这是编译器可验证的硬性要求；需显式标注@FunctionalInterface以启用编译期检查，继承、default、static及Object方法均不计入抽象方法数。
Java 函数式接口的核心规范就是：必须有且仅有一个抽象方法。这不是约定，而是编译器可验证的硬性要求，直接决定 Lambda 表达式能否被正确绑定。
必须显式标注 @FunctionalInterface
虽然不加该注解、只含一个抽象方法的接口也能被当作函数式接口使用，但强烈建议加上。它会触发编译器主动检查：
- 若接口中意外新增第二个 public abstract 方法，编译立即报错：
Unexpected @FunctionalInterface annotation - 继承了父接口（如 extends Runnable）后，父接口的抽象方法也会被计入总数，需一并核算
- 注解本身不改变运行行为，只提供编译期防护，避免后期重构引入隐性破坏
抽象方法数量必须严格为 1
判断依据是“可被实现类重写”的方法，以下情况均不计入抽象方法数：
-
default 方法：有方法体，属于接口自带能力，例如
Comparator.reversed() -
static 方法：属于工具方法，例如
Function.identity() -
Object 类公开方法：如
equals()、toString()、hashCode()，任何类都已有默认实现
注意：哪怕声明了 private abstract 或 protected abstract 方法（语法上不合法），Java 接口只允许 public abstract 方法；所有 abstract 方法，无论是否显式写 public，都算在内。
立即学习“Java免费学习笔记（深入）”；
抽象方法签名要清晰、可推断
Lambda 表达式依赖方法签名完成类型匹配，因此设计时需注意：
- 参数尽量用具体类型或泛型（如
T、String），避免自定义包装类导致推断失败 - 返回值类型明确，不推荐
Object或未约束通配符（如?） - 方法名不影响 Lambda 使用，但应语义准确，常见命名有
apply、test、get、accept、run
禁止出现多个抽象方法，哪怕看似无关
常见误踩的坑包括：
- 在接口里再加一个
void cleanup();—— 立即破坏函数式接口性质 - 同时继承两个函数式接口（如
extends Runnable, Supplier<Void>）—— 抽象方法叠加为两个 - 父接口已含抽象方法，子接口又定义新抽象方法 —— 总数超限
只要抽象方法数 ≠ 1，Lambda 就无法直接实例化该接口，编译器也不会接受类似 () -> {} 的写法。
