java lambda表达式无独立类型，其类型由上下文目标类型决定：变量声明、方法参数或返回值处的函数式接口类型即为目标类型，编译器据此反向推断并检查参数数量、类型兼容性及返回值匹配性。
Java Lambda 表达式没有独立类型，它的“类型”完全由使用它的上下文决定——这个上下文所要求的函数式接口类型，就是它的目标类型（Target Type）。编译器不是靠 Lambda 自身推导类型，而是先看它要赋给谁、传给谁、返回给谁，再反向确定它必须匹配哪个接口的方法签名。
目标类型从哪儿来？
目标类型只出现在明确的上下文中，比如：
- 变量声明：如
Runnable r = () -> System.out.println("ok");→ 目标类型是Runnable - 方法参数：如
Collections.sort(list, (a, b) -> a.compareTo(b));→ 第二个参数期待Comparator<t></t> - 方法返回值：如某个方法声明返回
Predicate<string></string>，你用return s -> s.length() > 0;，那这个 Lambda 就必须符合Predicate<string></string>
没有这些上下文，Lambda 就无法被识别为合法表达式。例如直接写 ((a,b) -> a.compareTo(b)).reversed() 会报错，因为编译器不知道它该是 Comparator 还是别的什么。
类型推断怎么工作？
一旦目标类型确定，编译器就根据该函数式接口中唯一的抽象方法签名，去检查 Lambda 是否匹配：
- 参数数量和顺序是否一致
- 每个参数能否接受传入的类型（支持自动装箱/拆箱，但不支持数值提升如
int → long） - 返回值类型是否与抽象方法的返回类型兼容（包括 void 和泛型擦除后的实际类型）
例如：Function<integer string> f = x -> x.toString();</integer> 中，x 被推为 Integer，因为 Function.apply(T) 接收一个 T；返回值也必须能转成 String，而 toString() 满足这一要求。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
参数类型可以省略，但不能乱加
只要目标类型清晰，参数类型通常可省略：
-
Consumer<string> c = s -> System.out.println(s);</string>✅ 编译器知道s是String -
BiFunction<number number double> add = (a, b) -> a.doubleValue() + b.doubleValue();</number>✅a和b被视为Number，可安全调用doubleValue()
注意：var 不能用于 Lambda 参数（Java 10+ 也不行），因为 var 的推断机制与目标类型推断逻辑冲突——前者依赖右侧表达式，后者依赖左侧接口。两者叠加会造成编译器无法确定优先级。
同一个 Lambda 可以适配多个接口
只要抽象方法签名兼容，一个 Lambda 就能对应不同函数式接口：
-
() -> 42可赋给Callable<integer></integer>，也可赋给PrivilegedAction<integer></integer>，因为二者都定义了无参、返回Integer的方法 -
(a, b) -> a.getWeight().compareTo(b.getWeight())可作为Comparator<apple></apple>、ToIntBiFunction<apple apple></apple>或BiFunction<apple apple integer></apple>使用，前提是目标位置接受它们
关键不在 Lambda 写了什么，而在它“被当成什么用”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
