为何嵌套通配符无法赋值给带类型参数的变量？

这个问题得从Java泛型的类型推断逻辑和通配符的本质差异入手，咱们通过两个示例对比着分析就明白了：

示例一：单层通配符的安全匹配 #

先看能正常编译的代码：

static class Generic<E> {}
static void run() {
    Generic<?> x = null;
    take(x);
}
static <E> void take(final Generic<E> x) {}

这里的Generic<?>里的通配符?，本质是某个确定的未知类型T——它不是“任意类型”，而是“我们暂时不知道具体是什么，但它是一个固定的类型”。

当调用take(x)时，编译器可以直接把方法的类型参数E推断为这个未知的T：不管T到底是String还是Integer，Generic<T>都完全符合Generic<E>的要求（毕竟E就是用来匹配任意单一类型的），所以这个赋值是绝对安全的，编译器自然放行。

示例二：嵌套通配符的不确定性陷阱 #

再看编译报错的代码：

static void run() {
    Generic<Generic<?>> x = null;
    take(x);
}
static <E> void take(final Generic<E> x) {}

这里的核心问题是嵌套通配符把“单一未知”变成了“任意未知”：

• Generic<Generic<?>>的外层容器里，每个元素都是Generic<?>——而这个内层的?代表的是“任意类型”，也就是说外层容器里可以同时装Generic<String>、Generic<Integer>、Generic<Double>这些完全不同的类型。
• 但take方法的参数Generic<E>要求：这个容器里的所有元素必须是同一个确定的类型E。

编译器根本找不到一个合适的E来匹配这种“任意性”：不管你把E推断成什么类型，都没法覆盖Generic<?>可能出现的所有情况。比如如果E是Generic<String>，但x里可能装着Generic<Integer>，这就会导致类型不兼容；反之亦然。

为了避免这种潜在的运行时类型错误，编译器直接拒绝了这个赋值操作——毕竟泛型的核心就是在编译期保证类型安全，这种无法确定统一类型的场景，自然过不了编译这一关。

内容的提问来源于stack exchange，提问作者Reinstate Monica