Java 编译器在方法调用上下文中会根据目标参数类型（而非构造表达式本身）进行泛型类型推断，使 new Pair(m1, m2) 可被视作 Pair，从而成功匹配 testPairEmployee(Pair) 方法签名。
java 编译器在方法调用上下文中会根据目标参数类型（而非构造表达式本身）进行泛型类型推断，使 `new pair(m1, m2)` 可被视作 `pair
这段代码看似违反直觉，实则精准体现了 Java 泛型类型推断（type inference） 与调用上下文（invocation context） 的深度协同机制。
关键在于：new Pair(new Manager(), new Manager()) 本身不是独立表达式，而是作为 testPairEmployee(...) 方法调用的实参出现——这使其成为一个poly expression（多态表达式）。根据 JLS §15.12，当方法调用具有明确的目标类型（target type）时，编译器会以该目标类型为指导，反向推断泛型参数。此处目标类型是 Pair<employee></employee>，因此推断结果为 Pair<employee></employee>，而非 Pair<manager></manager>。
验证这一点非常简单：启用详细类型解析日志（JDK 20+）：
javac --debug=verboseResolution=all Test.java
输出中明确显示：
立即学习“Java免费学习笔记（深入）”；
with actuals: Pair<Employee>
说明编译器已将该构造调用“适配”为 Pair<employee></employee> 类型。
⚠️ 对比之下，显式指定类型参数或强制转型会破坏这一机制：
// ❌ 编译错误：explicit type arg forces Pair<Manager> testPairEmployee(new Pair<Manager>(new Manager(), new Manager())); // ❌ 编译错误：cast context is NOT a poly context → inference ignores cast testPairEmployee((Pair<Employee>) new Pair<>(new Manager(), new Manager()));
原因在于：类型转换（cast）不构成 poly expression 上下文，new Pair(...) 在 cast 中被孤立推断，结果为 Pair<manager></manager>；而 Pair<manager></manager> 与 Pair<employee></employee> 在 Java 中不具继承关系（泛型是不变的/invariant），故不可强制转换。
✅ 正确理解应是：
-
Pair<t></t>是不变（invariant） 的——Pair<manager></manager>≠Pair<employee></employee>，也不为其子类； - 但 Java 允许在方法调用点通过目标类型驱动的类型推断，让
new Pair(...)“表现得像”所需类型，这是语法糖级别的便利设计，不改变运行时类型安全（所有类型检查仍严格基于擦除后逻辑）。
总结：这不是协变（covariance），而是上下文感知的类型推断。它提升了 API 易用性，但底层仍坚守泛型不变性原则。开发者应依赖此机制简化代码，但绝不假设 Pair<manager></manager> 可赋值给 Pair<employee></employee> 引用变量——后者需显式通配符（如 Pair extends Employee>）才能安全建模。
