函数式接口报错核心原因有三：抽象方法数量超限、Lambda中非法抛受检异常、多模块同名接口类加载冲突；需依现象反推，分别通过检查抽象方法定义、自定义带throws接口、统一收敛至专用domain-func模块解决。
函数式接口报错通常集中在编译期，核心原因就三个：抽象方法数量不对、受检异常写法越界、同名接口在多模块中重复定义。排查不靠猜，得按现象反推根源。
抽象方法超限：@FunctionalInterface 报错“not a functional interface”
这是最常见报错，编译器直接拒绝生成 class 文件，不是警告。
- 检查接口里所有未加 default 或 static 的方法——这些才算抽象方法；重写的 equals、hashCode、toString 不算，但参数签名必须完全匹配 Object 原方法
- 如果继承了多个父接口（比如同时 extends Runnable 和 AutoCloseable），而它们各自带 run() 和 close()，就会叠加出两个抽象方法 → 必须用 default close() { } 覆盖其中一个，或改用组合方式替代继承
- IDE 会实时标黄：光标悬停提示“contains 2 abstract methods”，Alt+Enter 可一键建议转为 default 方法
Lambda 写受检异常：编译报错“unreported exception XXX”
JDK 标准函数式接口（Function、Consumer 等）方法签名没声明 throws，所以你在 Lambda 里调用 Files.readString() 这类抛 IOException 的方法，编译器直接拦下。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 不能靠 try-catch 包一层再 return 就完事——那只是绕开语法，没解决接口契约问题
- 正解是自定义接口：@FunctionalInterface interface ThrowingSupplier
{ T get() throws IOException; } ，让异常声明落在接口上 - 再配一个静态适配器方法，把 ThrowingSupplier 转成标准 Supplier：内部用 UncheckedIOException 包装，既保留原始异常类型，又不破坏 Stream 流式调用
运行时报 LinkageError 或 IncompatibleClassChangeError
这类错误不编译失败，但一执行 Lambda 就崩，堆栈常指向 invokedynamic 或 LambdaMetafactory，典型特征是本地跑得通、上线偶发崩溃。
立即学习“Java免费学习笔记（深入）”；
- 先用 -verbose:class 启动 JVM，看同名接口（如 com.example.func.Mapper）被哪个 jar 加载了几次
- 线上用 Arthas 执行 sc -d com.example.func.Mapper，确认是否被不同 ClassLoader 加载；再用 jad 反编译比对字节码来源
- 根治办法是收敛契约：建独立的 domain-func 模块，只放接口定义，其他模块删掉同名定义，Maven 中用
阻断冗余依赖
不复杂但容易忽略：加 @FunctionalInterface 不是可选装饰，而是契约声明。不加它，别人可能悄悄加个抽象方法，导致所有 Lambda 调用点集体编译失败，问题分散难定位。
