java泛型方法类型推导是编译期基于实参类型、目标类型和方法签名的逻辑收敛：实参类型优先确定t，目标类型校准推断结果，多参数协同约束收窄类型，推导失败时编译报错而非随意选择。
Java泛型方法的类型推导不是“猜测”，而是编译器基于明确约束条件进行的逻辑收敛。它不依赖运行时，也不靠经验判断，而是在编译期根据参数类型、目标类型和方法签名三者联动完成匹配。
核心依据：实参类型优先
编译器首先看传入的实际参数（实参）类型，将其与泛型方法形参的占位类型（如 T）对齐。只要所有实参在同一个类型变量下能统一到一个具体类型，就直接采用。
-
单一参数场景：调用
Util.identity("hello")，实参是String，形参是T value→ 直接推为T = String -
多参数同类型场景：调用
pick("a", "b")，两个T形参都对应String→ 推为T = String -
多参数不同类型场景：调用
pick("a", new ArrayList())，两者无共同子类，但有公共父接口（如Serializable或Comparable）→ 推为最具体的公共上界，比如T = Serializable
辅助依据：目标类型（Target Type）参与校准
当方法有返回值，且该返回值被赋给某个变量或用于表达式时，左侧声明的类型会反向影响推断结果，尤其在多个可能类型存在时起决定作用。
- 写成
String s = pick("x", "y")，目标类型是String，强化了T = String的结论 - 写成
Serializable s = pick("x", new Date())，目标类型限定了上界，即使实参分别是String和Date，也只会推为它们共同实现的Serializable，而非更宽泛的Object - Lambda 表达式中尤为明显：
list.sort(comparing(a -> a.getName()))，因为list是List<person></person>，所以comparing的T被锁定为Person，进而让a自动获得Person类型，a.getName()才能通过检查
进阶机制：多类型参数协同约束
当方法声明含多个泛型参数（如 <t u></t>），编译器会联合分析各参数之间的关系，按约束链逐层收窄。
- 例如
<t u extends comparable>> Comparator<t> comparing(Function<t u>)</t></t></t>，先由外部容器确定T（如Person），再根据Function的返回值类型（如String）确认U必须是String（因String implements Comparable<string></string>） - 若传入
comparing(p -> p.getAge())，而getAge()返回int，则U推为Integer（自动装箱后满足Comparable<integer></integer>）
边界情况：推导失败时的表现
类型推导不是万能的。当约束冲突或信息不足，编译器会报错，而不是“随便选一个”。
- 调用
pick(null, null)：两个实参都是null，无类型线索 → 编译失败，需显式写成pick<string>(null, null)</string> - 调用
newArrayList()且未赋值给带泛型的变量：无实参、无目标类型 → 推为Object，但后续使用可能触发 unchecked warning - 方法重载 + 泛型推导模糊：比如两个泛型方法签名太接近，编译器无法唯一确定调用哪个 → 编译错误，必须加尖括号指定类型
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
