函数式接口与普通接口的核心区别在于抽象方法数量及用途：前者有且仅有一个显式声明的抽象方法（sam原则），专为lambda表达式设计；后者可含多个抽象方法，用于定义类的行为契约。
函数式接口和普通接口的核心区别在于抽象方法的数量与使用场景：函数式接口有且仅有一个抽象方法，专为 Lambda 表达式或方法引用设计；普通接口则面向行为契约，可定义多个抽象方法，用于规范类的实现结构。
抽象方法数量是硬性分水岭
函数式接口必须满足“单一抽象方法（SAM）”原则。这个“一个”是指除 Object 类继承来的方法（如 equals、hashCode、toString）外，显式声明的、未被 default 或 static 修饰的抽象方法只能有一个。
- ✅ 合法：Comparator 接口有 compare() 和 equals()，但 equals() 是对 Object 方法的重写，不算额外抽象方法
- ✅ 合法：Runnable 只有 run()，是典型函数式接口
- ❌ 非法：若自定义接口声明了 doWork() 和 doCleanup() 两个无实现的抽象方法，即使加了 @FunctionalInterface，编译也会报错
用途导向决定选型
选函数式接口还是普通接口，关键看你要解决什么问题：
- 需要传一段可执行逻辑（比如排序规则、数据处理动作、异步回调）→ 选函数式接口。例如用 Function
做字符串转数字，用 Predicate 做条件过滤 - 需要定义一组相关行为并由多个类共同实现（比如支付渠道统一有 pay()、refund()、queryOrder()）→ 选普通接口。它强调职责划分与多态扩展，不是为 Lambda 服务的
- 想把策略逻辑内联到调用点，避免新建类或匿名内部类 → 函数式接口 + Lambda 更简洁
@FunctionalInterface 注解的作用
这个注解不是函数式接口的必要条件，但强烈建议加上：
- 它是给编译器的“说明书”：一旦接口不符合 SAM 规则，立即报错，防止后期误加方法破坏函数式语义
- 它是给团队的“信号灯”：看到这个注解，开发者立刻明白该接口预期用 Lambda 实现，而非传统 implements
- 不加也能用（如原始 Runnable 就没加），但加了更安全、更清晰
默认方法和静态方法不影响函数式性质
Java 8+ 允许接口包含 default 和 static 方法，它们有具体实现，不属于抽象方法范畴：
- 一个接口可以有 5 个 default 方法 + 2 个 static 方法 + 1 个抽象方法 → 仍是合法函数式接口
- 这些非抽象方法可用于增强函数式接口的能力，比如在 Predicate 中添加 and()、or() 默认组合逻辑
- 普通接口同样支持 default/static，但这不是它和函数式接口的本质区别
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
