函数式接口的核心是仅含一个待实现的抽象方法；抽象方法指未实现的public abstract方法（含接口默认隐式的），不包括object继承方法、default方法和static方法。
函数式接口的核心，就是“只允许一个待实现的抽象方法”。它不是说整个接口只能有一个方法，而是强调：在所有方法中，必须且只能有一个没写具体实现、需要调用方去补全的方法。
抽象方法到底指哪些？
判断时只看真正需要被实现的方法：
- 用 abstract 修饰、没有方法体的方法（即使没写 abstract 关键字，接口里普通方法默认就是 abstract）
- 从 Object 类继承的方法（如 toString()、equals()、hashCode()）不计入——它们是隐式存在的，不是你定义的抽象行为
- default 方法有实现体，static 方法属于接口自身，都不算抽象方法
@FunctionalInterface 注解的作用
它不是让接口变成函数式接口的“开关”，而是编译器的“校验员”：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 加了这个注解，编译器会检查：抽象方法是不是恰好一个？不是就直接报错
- 不加也能用（只要满足单抽象方法），但失去提前发现错误的机会
- 它不改变运行逻辑，只提升代码可维护性和团队协作安全性
为什么必须是“接口”，不能是抽象类？
因为函数式接口的设计目标是支持 Lambda 表达式和方法引用，而 Java 的 Lambda 只能用来实例化接口类型：
- 抽象类可以有构造器、字段、多种访问修饰符，结构更重，不适合做“行为参数”的轻量载体
- 接口天然无状态、纯契约，配合 Lambda 就像给一个动作起个名字，比如“给一个数，返回它的平方”——这就是 Function
- Lambda 的语法 () -> {} 或 x -> x * x，背后绑定的是接口的抽象方法签名，不是抽象类的抽象方法
常见误区澄清
容易混淆的几种情况：
- 接口里有多个 default 方法？没问题——它们已有实现，不增加使用者负担
-
接口继承另一个接口，导致抽象方法变两个？危险！ 比如 interface A extends Runnable, Callable
，就含 run() 和 call() 两个抽象方法，不再是函数式接口 - 重写了 Object 的方法算不算新增抽象方法？不算——哪怕你写 public abstract boolean equals(Object o); 编译器也不认它为新抽象方法，仍按 Object 规则处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
