java lambda类型推导以目标类型为起点，反向锁定参数与返回值类型；通过函数描述符确定方法签名约束；泛型方法调用时类型层层传导形成闭环；显式参数类型可覆盖推导，但var被禁止。
Java 编译器对 Lambda 表达式的类型推导，不是“猜”，而是严格按上下文契约反向锁定——它不看 lambda 本身写了什么，而是先看“它要塞进哪个接口里”，再倒推出参数和返回值该是什么类型。
目标类型是起点，不是结果
编译器第一步永远是定位目标类型（Target Type）：即 Lambda 所赋值的变量类型、所传入的方法参数类型，或所实现的函数式接口声明。例如：
-
List<person> list = ...; list.sort(Comparator.comparing(a -> a.getName()));</person>→ 目标类型是Comparator<person></person> -
Predicate<string> p = s -> s.isEmpty();</string>→ 目标类型是Predicate<string></string>
这个目标类型决定了后续所有推导的边界。没有目标类型，Lambda 就无法编译——它本身没有独立类型，只是函数式接口的一个实例占位符。
函数描述符决定参数与返回值的骨架
一旦确定目标类型，编译器立刻查它的函数描述符（Function Descriptor），也就是那个唯一抽象方法的签名。比如：
-
Predicate<t></t>的抽象方法是boolean test(T t)→ 函数描述符为T → boolean -
Comparator<t></t>是int compare(T o1, T o2)→ 描述符为(T, T) → int
于是，s -> s.isEmpty() 中的 s 类型必须是 String，因为只有这样才能满足 test(String)；a -> a.getName() 中的 a 必须是 Person，才能调用 getName() 并返回 String（进而满足 Function<person string></person> 的约束）。
泛型约束会层层传导，形成类型闭环
在涉及泛型方法（如 Comparator.comparing()）时，推导更进一步联动：
-
comparing(Function super T, ? extends U>)被调用时，T 已由外部（sort(Comparator<person>)</person>）固定为Person - 于是
Function super Person, ?>的输入参数被锚定为可接受Person及其父类，而最具体、最安全的绑定就是Person - 编译器由此确认 lambda 参数
a的静态类型是Person，再检查a.getName()是否存在、返回值是否实现Comparable，最终完成全链验证
显式类型可覆盖推导，但 var 不行
你可以写 (String s) -> s.length() 显式声明参数类型，这会跳过推导直接匹配；但不能写 (var s) -> s.length() —— Java 规范禁止在 lambda 参数中使用 var，因为这会破坏目标类型驱动的单向推导逻辑，引入语法歧义和解析不确定性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
