Java Lambda在泛型方法调用中的类型推断由编译器依据方法签名、目标接口和变量声明三重约束自外向内逐步收敛得出，而非主观猜测；例如Comparator.comparing中T被list.sort的List<Person>反向锁定为Person，从而确定a参数类型为Person，并推导出U为String；约束模糊时推断失败，需显式标注类型。
Java 中 Lambda 表达式在泛型方法调用时的隐式类型推断，不是靠“猜”参数类型，而是由编译器沿着方法签名、目标接口契约和变量声明三者构成的约束链，自外向内逐步收敛得出的。
泛型方法签名是推断的起点
比如 Comparator.comparing(Function<? super T, ? extends U> keyExtractor) 这个静态方法，它的泛型参数 T 和 U 并非孤立存在。当它被用于 list.sort(Comparator.comparing(a -> a.getName())) 时：
-
list是List<Person>，所以sort方法要求传入Comparator<? super Person> - 该约束反向锁定
comparing中的T必须是Person（或其父类），而取最具体可行类型就是Person - 于是
keyExtractor的实际期望类型就确定为Function<? super Person, ? extends U>
Lambda 参数类型由此自然确定
一旦函数式接口类型明确，Lambda 就必须适配其抽象方法签名：
-
Function.apply(Person a)要求参数能接收Person实例 - 所以
a -> a.getName()中的a静态类型就是Person - 编译器接着验证
Person.getName()是否存在且返回String，再据此推出U = String
类型不匹配时推断会失败
如果上下文约束模糊或冲突，编译器无法唯一确定类型，就会报错：
立即学习“Java免费学习笔记（深入）”；
- 比如把
comparing(a -> a.getName())放在未声明泛型的原始类型调用中，T无法绑定，a类型推断失败 - 又如
Function<Object, String>和Function<Person, String>同时可选，编译器不会随意选一个，而是直接拒绝 - 此时需显式写出参数类型：
comparing((Person a) -> a.getName())来打破歧义
IDE 提示也依赖同一套机制
你看到的代码补全（如输入 a. 就弹出 getName()）不是 IDE 猜的，而是它复用了 javac 的目标类型推断逻辑：
- 解析到当前 Lambda 所处位置的目标类型是
Function<Person, String> - 于是将
a视为Person类型，加载其所有 public 方法供提示 - 这说明类型推断在编辑期和编译期使用的是同一套语义规则
