Lambda表达式无独立类型，其类型由上下文目标类型决定；编译器根据函数式接口方法签名反向验证参数、返回值及异常兼容性，实现约束驱动的隐式转型。
lambda 表达式本身没有独立类型，它的类型完全由使用它的上下文决定——这个上下文所期待的类型，就是它的目标类型（target type）。编译器不是“猜测”lambda是什么类型，而是根据目标类型反向验证：这个lambda能否合法地充当那个函数式接口的实例。
这种机制本质上是一种约束驱动的隐式转型，而非自由转换。它不改变Lambda的结构，但要求其签名与目标接口的方法签名严格匹配。
目标类型如何触发隐式转型
当 Lambda 出现在以下位置时，编译器立即识别出目标类型，并据此检查兼容性：
- 赋值语句右侧
- 方法参数传入处
-
return语句中返回函数式接口类型 - 数组初始化器中作为元素
- 泛型方法调用的实参（结合类型推导）
例如：
Comparator<String> comp = (s1, s2) -> s1.compareToIgnoreCase(s2);
这里 Comparator<String> 是明确的目标类型。编译器会检查：
-
Comparator<String>是函数式接口（✅，只有一个抽象方法compare） - Lambda 参数个数（2）、类型（
String, String）与compare(String, String)一致（✅） - 返回值类型（
int）与compare方法声明的返回类型兼容（✅） - Lambda 内部未抛出
Comparator.compare声明之外的受检异常（✅）
全部满足，编译通过——Lambda 就被“转型”为 Comparator<String> 实例。
隐式转型的关键限制
这不是无条件的自动适配，而是一套双向校验规则：
- 目标类型必须是函数式接口（有且仅有一个抽象方法）
- Lambda 参数类型若未显式写出，由目标方法参数类型反推（如
(a, b) -> a + b中a,b类型来自目标接口） - 返回值类型必须能赋值给目标方法的返回类型（支持自动装箱、向上转型，但不支持向下转型或丢失精度的数值转换）
- 若 Lambda 抛出异常，该异常必须在目标方法
throws子句中声明（或为非受检异常）
常见失败情形：
- 把
() -> "hello"赋给Supplier<Integer>（返回类型不兼容） - 把
(x) -> x.length()传给Function<String, Integer>却误写成Function<Integer, Integer>（参数类型不匹配） - 在需要
Runnable的地方写(int n) -> {}（参数个数多于目标方法）
同一个 Lambda 可以有多个目标类型
因为转型依赖上下文，同一段 Lambda 文本可合法对应不同接口：
Callable<String> c = () -> "done"; PrivilegedAction<String> p = () -> "done";
两个目标类型不同，但都要求“无参、返回 String”，所以同一个 () -> "done" 可同时满足。这说明：Lambda 的“类型”是动态绑定的，不是静态固化的。
和普通类型转换的区别
普通类型转换（如 int → long）是值层面的提升或收缩；
Lambda 的“隐式转型”是语义契约层面的适配：它把一段代码块，按目标接口约定的“调用协议”进行封装，生成符合该协议的对象实例。背后可能生成私有静态内部类，也可能复用缓存对象，但对外完全透明。
编译期完成全部校验，运行期不进行类型转换动作——所谓“隐式”，是指你不用写 new SomeInterface() { ... }，也不用强制转型，但一切合法性已在编译时锁定。
不复杂但容易忽略
