Java编译器推断Lambda类型依赖目标函数式接口上下文，方法重载导致上下文歧义时需显式标注参数类型或补全类型信息。
Java 编译器对 Lambda 表达式的类型推断，依赖于**目标函数式接口的上下文**。当方法重载存在时，若多个重载方法都可接受 Lambda，但它们期望的函数式接口不同（比如 Predicate<String> 和 Consumer<Object>），编译器就无法唯一确定目标类型，进而无法反推 Lambda 参数类型——这时就会在 s -> ... 处报错，表面看是语法问题，实则是上下文歧义。
明确目标函数式接口是关键
编译器不“猜”接口，只“匹配”已知契约。只要调用点能唯一指向一个函数式接口，参数类型自然可推。常见有效做法：
-
优先使用方法签名差异大的重载：比如一个接收
Runnable，另一个接收Supplier<String>，编译器能靠返回类型或参数个数立刻区分，无需显式标注 -
避免仅靠泛型参数区分的重载：如
process(List<String>)和process(List<Integer>)，因泛型擦除，Lambda 传入时编译器看到的都是process(List)，极易推断失败 -
在调用处补全类型信息：比如把 Lambda 赋给具名变量再传入，变量声明即提供强上下文：
Predicate<String> p = s -> s.length() > 0;
process(p);
显式标注参数类型是最直接的解法
当重载方法形参都是函数式接口、且抽象方法签名相似（如都含一个参数）时，最稳妥的方式就是在 Lambda 中写明参数类型：
- (String s) -> s.trim().isEmpty() —— 明确告诉编译器 s 是 String
-
(int idx) -> list.get(idx).getName() —— 强制 position 为 int，避免和
Integer或泛型 T 混淆 - 注意：不能混用，比如 (var s, String t) 是非法的；要么全用
var（Java 11+），要么全写具体类型
检查函数式接口定义是否规范
Lambda 能否被识别，前提是它真能“套进”某个接口。务必确认：
立即学习“Java免费学习笔记（深入）”；
- 接口上加了
@FunctionalInterface注解，且确实只有一个抽象方法 - 抽象方法的参数类型与你要写的 Lambda 逻辑一致（例如回调要取列表项，方法签名就该是
void onItemClick(int position)，而不是onItemClick(Object o)） - 构造函数或方法参数中引用的接口类名、包路径完全正确，IDE 提示 “cannot resolve symbol” 往往就是导入错误或拼写错误
用强制类型转换临时绕过歧义
适用于无法修改接口或方法签名的场景，属于“兜底手段”：
- process((Predicate<String>) s -> s != null);
- setOnClickListener((View.OnClickListener) v -> doClick());
- 缺点是略显冗长，且过度使用会掩盖设计问题；建议仅用于迁移旧代码或调试定位
