Java Lambda类型推断依赖目标类型：编译器根据赋值或传参的函数式接口确定参数与返回值类型，检查接口唯一性、签名匹配及异常声明，无上下文或重载歧义时推断失败。
Java 中 Lambda 表达式的类型推断，不是靠表达式自身“猜”类型，而是依赖它被赋值或传入的目标类型（Target Type）——也就是上下文明确要求的那个函数式接口类型。
目标类型决定一切
编译器不会孤立地看 (a, b) -> a + b，而是看它出现在哪儿：
- 如果写在
BinaryOperator<integer> op = (a, b) -> a + b;</integer>中，目标类型是BinaryOperator<integer></integer>，那a和b就自动推为Integer，返回值也必须是Integer； - 如果写在
Predicate<string> p = s -> s.isEmpty();</string>中，目标类型锁定为Predicate<string></string>，所以s就是String，方法体必须返回boolean； - 如果用在
Thread t = new Thread(() -> System.out.println("ok"));，目标类型是Runnable，所以参数为空、返回为void。
推断发生在编译期，不靠运行时
这个过程完全由 javac 完成，和 JVM 运行无关。它基于 Java 语言规范定义的“目标类型推断规则”，检查三点：
- 目标接口是否为函数式接口（只有一个抽象方法）；
- Lambda 参数个数、顺序是否与该抽象方法签名匹配；
- Lambda 主体的返回值、异常是否符合该方法的声明。
一旦不匹配，比如把 (x, y) -> x + y 赋给 Consumer<integer></integer>，编译直接报错——因为 Consumer 的 accept 方法不返回值，而你的表达式有返回值。
立即学习“Java免费学习笔记（深入）”；
不能推断的常见情况
类型推断虽智能，但也有边界：
-
单独写 Lambda 没有上下文：比如
var lambda = (x, y) -> x - y;在 Java 10+ 中会编译失败，因为var需要右侧有明确类型，而 Lambda 自身无类型； -
重载方法调用歧义：如果一个类有两个重载方法，都接受函数式接口但类型不同（如
foo(Runnable)和foo(Callable<void>)</void>），传入() -> {}可能导致编译错误，需强制转型或改用显式类型； -
泛型方法类型参数未绑定：如
<t> void process(T t, Function<t string> f)</t></t>，若调用时没提供足够类型线索（例如process("s", x -> x)），可能推断失败。
显式类型 vs 推断：什么时候该写出来？
大多数时候可以省略，但以下场景建议显式写出参数类型：
- 提升可读性：当逻辑复杂或参数语义不明显时，比如
(User u, Order o) -> u.getId().equals(o.getUserId())比(u, o) -> ...更清晰； - 解决歧义：当编译器无法唯一确定类型（如上文重载场景），加类型可快速修复；
- 与 IDE 协作更稳：某些老版本 IDE 或复杂泛型链中，显式类型有助于补全和提示。
