函数式接口编译报错的核心原因是抽象方法数量不为1或方法签名违反契约：必须有且仅有一个未被default/static修饰、非Object重写的抽象方法；继承叠加、误加异常、缺失@FunctionalInterface注解均会触发错误。
函数式接口编译报错，核心就两点：抽象方法数量不对，或方法签名违反函数式契约。不是语法写错了，而是定义违背了 @FunctionalInterface 的硬性规则——编译器会直接拒绝生成 class 文件，不给商量余地。
检查抽象方法是否唯一
函数式接口必须且只能有一个**未被 default 或 static 修饰的、非重写 Object 公共方法**的抽象方法。
- 删掉多余抽象方法，只保留一个核心行为（如
apply、get、accept） - 把次要行为改成
default方法（例如日志、校验、空值处理），它们不计入计数 - 注意重写
equals(Object)、hashCode()、toString()是安全的；但写成equals(String)就算新增抽象方法，会触发冲突 - 用 IntelliJ 或 Eclipse 时，光标悬停在接口名上，IDE 会直接提示 “Not a functional interface: contains X abstract methods”
排查继承导致的抽象方法叠加
如果接口同时继承了 Runnable 和 AutoCloseable，就会带入 run() 和 close() 两个抽象方法，必然报错。
- 在子接口中用
default void close() {}覆盖掉其中一个，让它不再抽象 - 或者放弃多继承，改用组合方式：例如类里持有一个
Runnable字段 + 一个Closable字段，而不是让接口去实现两者 - Ctrl+Click 跳转到
Comparator或Predicate看标准写法，对照自查结构是否干净
确认是否误用受检异常
Lambda 体里调用了可能抛 IOException 的方法，但函数式接口方法没声明 throws，编译器会报 “Unhandled exception”。
立即学习“Java免费学习笔记（深入）”；
- 不能在标准
Consumer、Function上直接加throws，那是语法错误 - 需要自定义接口，例如
interface ThrowingSupplier<T> { T get() throws Exception; } - 再配一个工具方法把
ThrowingSupplier转成普通Supplier，内部用try-catch + RuntimeException(e)包装 - 不推荐在 Lambda 里写大段
try-catch，逻辑复杂时应抽出为独立方法并显式声明异常
别忽略 @FunctionalInterface 的文档价值
不加这个注解，代码可能暂时编译通过，但隐患更大。
- 别人后续不小心加了个抽象方法，所有使用该接口的 Lambda 都会突然编译失败
- 错误分散在各处调用点，排查成本高
- 失去语义表达力——其他开发者无法一眼判断这个接口本意是用于函数式编程
- 加上注解后，IDE 和编译器能提前拦截违规修改，相当于加了一道类型安全的护栏
