本文深入解析Java中泛型类嵌套使用时的类型兼容性限制，阐明C并非C子类型的根本原因，并提供基于通配符（? extends T）的安全、通用解决方案。
本文深入解析java中泛型类嵌套使用时的类型兼容性限制，阐明c并非c子类型的根本原因，并提供基于通配符（? extends t）的安全、通用解决方案。
在Java面向对象与泛型结合的实践中，一个常见却易被误解的问题是：当存在继承关系 B extends A 时，为何 C<B> 无法作为参数传递给期望 C<A> 类型的方法？例如：
class A {}
class B extends A {}
class C<T> {
void m(T t) {}
}
C<C<A>> container = new C<>();
C<B> obj = new C<>();
container.m(obj); // 编译错误！该调用失败的根本原因在于——Java泛型是不变的（invariant）。这意味着即使 B 是 A 的子类，C<B> 和 C<A> 在类型系统中被视为完全无关的两个独立类型，二者既无继承关系，也不可互相赋值。这与数组不同（数组是协变的，如 B[] 可赋值给 A[]），泛型为保障类型安全而刻意设计为不变。
从语义上展开理解：C<A> 实际定义了一个接受 A 或其子类实例的方法 m(A t)；而 C<B> 定义的是 m(B t)。若允许 C<B> 被当作 C<A> 使用，则可能在运行时向 C<B> 的 m() 方法传入一个非 B 类型的 A 子类实例（如 C<C>），从而破坏类型契约。因此，编译器严格禁止此类隐式转换。
✅ 正确解法是使用有界通配符：将目标类型声明为 C<? extends A>，表明“接受任何 C<T>，只要 T 是 A 的子类型（含 A 自身）”。这样，C<B> 就合法匹配 C<? extends A>，因为 B extends A 成立。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
修正后的完整可运行示例：
public class Test {
class A {}
class B extends A {}
class C<T> {
void m(T t) {}
}
void test() {
// 关键修改：使用通配符上限，声明容器可接收任意 C<? extends A>
C<C<? extends A>> container = new C<>();
C<B> obj = new C<>();
container.m(obj); // ✅ 编译通过
}
}⚠️ 注意事项：
- C<? extends A> 表示“读取友好（producer）”，可用于获取 T 类型的实例（如 T get()），但不可向其中写入（除 null 外），因编译器无法确定具体 T；
- 若需写入能力，应考虑 C<? super B>（消费者场景），但本例中不适用；
- 嵌套泛型（如 C<C<? extends A>>）虽语法合法，但会显著增加可读性负担，建议配合类型别名（通过静态内部类或封装类）提升代码可维护性。
总结：Java泛型的不变性是类型安全的基石。面对嵌套泛型的类型兼容需求，应主动采用 ? extends T（协变读取）或 ? super T（逆变写入）进行精确建模，而非依赖不存在的“自动继承推导”。
