函数式接口是仅含一个抽象方法的接口，可含任意默认方法、静态方法及object类继承方法；@functionalinterface注解用于显式标识并触发编译器校验，非必需但推荐。
直接看接口定义，重点确认它是否真的只含一个抽象方法。
看有没有 @FunctionalInterface 注解
这是最直观的信号。加上这个注解后，编译器会强制校验：如果接口里多于一个抽象方法，就会报错。但注意——没加注解不等于不是函数式接口，只是少了这层保护；加了却报错，说明接口本身不符合要求。
- 打开你用在 Lambda 处的目标接口（比如 User::getName 对应的接口）
- 检查顶部是否有 @FunctionalInterface
- 如果有，再逐个看接口里的方法：排除 default 方法、static 方法、Object 的 public 方法（如 toString、equals），只数真正未实现的抽象方法
手动数抽象方法，别被 default 和重载骗了
函数式接口允许有多个 default 方法、任意 static 方法，甚至重载的抽象方法——但只要有两个以上非重载的抽象方法，就不合法。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 例如接口里有 String get(); 和 void set(String s); → 两个抽象方法 → 不是函数式接口
- 如果有 default void log() {} 和 String name(); → 只有一个抽象方法 → 合法
- 如果写了 int getValue(); 和 long getValue(); → 编译报错（重复方法名），不算两个抽象方法，但这种写法本身非法，需先修正
查报错位置对应的实际类型
像 “Object is not a functional interface” 这类错误，往往是因为传入了 Class 类型（如 User.class）而非方法引用（User::getName）。IDE 通常会在红色波浪线下提示“Expected functional interface”。
- 把光标停在报错的 Lambda 或方法引用上，按 Ctrl+Click（IntelliJ）或 F3（Eclipse）跳转到目标签名
- 观察该处参数声明的类型，比如
QueryWrapper 中的 R，它应是泛型限定为函数式接口（如 SerializableFunctioneq(R column, Object val) ） - 如果发现 R 实际被推导成 Object 或 Class>，说明方法引用写错了，比如用了 User.class::getName 而不是 User::getName
用 IDE 快速验证是否可接受 Lambda
不用猜，让工具说话。把光标放在疑似问题的表达式左侧，看 IDE 是否给出「Lambda expression expected」提示；或者把现有 Lambda 替换为 () -> {}，看是否仍报同类型错误。
- 若替换后错误消失 → 原 Lambda 本身语法或类型不匹配
- 若替换后仍报 “not a functional interface” → 问题出在接收方接口定义，不是 Lambda 写法问题
- 在 IntelliJ 中，按 Alt+Enter 可快速查看「Expected type」和「Inferred type」，对比二者是否一致
