函数式接口方法签名不匹配本质是Lambda或方法引用的参数个数、类型、返回值与接口唯一抽象方法不一致；需确认接口确为函数式接口、核对签名是否严格匹配，并在必要时显式声明类型或更换适配接口。
函数式接口方法签名不匹配，本质是 Lambda 表达式或方法引用的参数个数、类型、返回值与接口中唯一的抽象方法不一致。改法核心是让两边“对得上”——要么调整 Lambda，要么检查接口定义是否真为函数式接口，或确认是否误用了非函数式接口。
确认目标接口确实是函数式接口
Java 要求函数式接口有且仅有一个抽象方法（默认方法和静态方法不影响）。常见错误是误用含多个抽象方法的接口（如自定义接口没加 @FunctionalInterface 但实际写了两个 abstract 方法）。
- 加上 @FunctionalInterface 注解，编译器会帮你检查是否符合要求
- 用 IDE 快捷键（如 IntelliJ 的 Ctrl+Click）跳转到接口源码，确认只有一个 abstract 方法
- 例如：若写了一个叫 Calculator 的接口，却定义了 add() 和 subtract() 两个 abstract 方法，它就不是函数式接口，不能用于 Lambda
核对 Lambda 参数与抽象方法签名是否一致
这是最常见原因。比如接口定义的是 Function
- 参数数量要相同：接口方法形参 1 个，Lambda 就只能写 1 个参数（可省略括号），不能多也不能少
- 参数类型要能自动推导或显式匹配：如接口方法是 accept(Object o)，Lambda 写 (String s) -> {...} 就可能失败（除非重载或类型明确）
- 返回值类型需兼容：Lambda 体最后的表达式或 return 语句的类型，必须能赋值给接口方法声明的返回类型
方法引用时注意目标方法的签名
写 String::length 是合法的，因为它是无参、返回 int，匹配 Supplier
立即学习“Java免费学习笔记（深入）”；
- 静态方法引用：ClassName::staticMethod → 方法参数列表（不含类名）必须与函数式接口抽象方法一致
- 实例方法引用：obj::instanceMethod → 方法参数数 = 接口方法参数数 − 1（因为隐含了调用对象 this）
- 特定类型实例方法引用：String::compareTo → 接口方法需是接收两个 String 的 BiFunction 或类似结构
必要时显式声明参数类型或换用匹配的接口
当类型推导失败（尤其涉及泛型或重载方法时），可手动补全类型信息；或者发现现有函数式接口确实不适用，就选更贴切的 JDK 接口（如 UnaryOperator、BinaryOperator、Predicate）或自定义一个。
- 在 Lambda 中写 (String s) -> s.toUpperCase() 比 s -> s.toUpperCase() 更明确，有助于绕过类型歧义
- 如果业务逻辑需要两个入参一个出参，别硬套 Consumer
（它不返回值），改用 BiFunction - 自定义接口时，确保只保留一个 abstract 方法，并用 @FunctionalInterface 标注
