函数式接口必须有且仅有一个抽象方法；default、static方法及重写的object公共方法（如equals、hashcode）不计入抽象方法数量。
直接删掉多余的抽象方法，或者把其中一些改成 default 或 static 方法。这是最根本的解决方式——因为函数式接口的定义就是“有且仅有一个抽象方法”，编译器报错不是警告，而是拒绝生成 class 文件。
哪些方法不算抽象方法？
判断是否违规，关键在于准确识别“抽象方法”的范围：
- 显式声明的
void run()、int calc(int x)这类没加default或static的，算抽象方法 - 用
default修饰的方法（如default void log() { ... }），不算抽象方法，可任意添加 - 用
static修饰的方法（如static String of(String s) { ... }），也不算抽象方法 - 重写
Object的公共方法（equals(Object)、hashCode()、toString()），即使没加default，也不计入抽象方法数量 - 但注意：如果写成
boolean equals(String s)（参数类型不同），这就成了新抽象方法，会触发冲突
继承多个父接口时怎么处理？
如果当前接口继承了 Runnable 和 AutoCloseable，而两者分别带 run() 和 close()，编译器会认为有两个抽象方法 → 报错。解决办法只有两种：
- 在当前接口中用
default覆盖其中一个（例如default void close() {}），使其不再抽象 - 或者不继承冲突接口，改用组合或适配器模式，避免抽象方法叠加
IDE 能提前帮你发现吗？
可以。IntelliJ 和 Eclipse 都支持实时检查：
- 光标悬停在接口名上，会提示 “Not a functional interface: contains X abstract methods”
- 多出的抽象方法行会出现黄色波浪线，Alt+Enter 可快速建议转为
default - Ctrl+Click 跳转到
Comparator或Predicate等 JDK 标准函数式接口，对照结构自查
不加 @FunctionalInterface 就不会报错？
确实不会编译报错，但隐患更大：
- 别人可能在你不知情时加了个抽象方法，导致所有使用该接口的 Lambda 突然编译失败
- 错误分散在各处调用点，排查成本高
- 失去自文档性——其他开发者无法一眼看出这个接口本意是用于函数式编程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
