为何Java方法参数与通配符无法互换使用？

你碰到的这个问题，本质是泛型里协变/逆变规则和通配符与类型参数的差异在搞鬼，咱们把它拆开来捋清楚：

先看为什么l1 = l2能正常编译 #

Consumer<List<? extends Number>>在这里是一个确定的类型——虽然里面带了通配符，但它是一个完整的类型描述。两个完全相同的类型之间赋值，编译器当然不会拦着，就像你把String变量赋值给另一个String变量一样自然。

核心问题：Consumer<List<T>>为啥不能转成Consumer<List<? extends Number>>？ #

要搞懂这个，得先回忆Consumer的泛型特性：Consumer<U>是逆变的。啥意思？简单说就是，如果U1是U2的父类型，那Consumer<U2>就是Consumer<U1>的子类型。举个例子：Consumer<Number>可以赋值给Consumer<Integer>，因为Number是Integer的父类，逆变反转了Consumer的类型关系。

回到你的代码：

• T是一个具体的、被限定为Number子类的类型参数（比如可能是Integer、Double，或者自定义的Number子类）。
• List<? extends Number>代表的是任意Number子类的List，它是所有List<T>（T extends Number）的父类型。

根据逆变规则：
List<T>是List<? extends Number>的子类型 → Consumer<List<T>>是Consumer<List<? extends Number>>的父类型。

哦！原来你是在尝试把一个父类型的引用赋值给子类型的变量——这就像你不能把Object直接赋值给String一样，编译器会直接阻止这种不安全的操作。

换个更直观的角度想：如果允许这个赋值，那你可以通过l3传入一个List<Double>（因为它属于List<? extends Number>），但原来的Consumer<List<T>>（比如T=Integer）只能处理List<Integer>，这会直接导致类型安全问题，所以编译器干脆在编译阶段就把这个漏洞堵上了。

解决方法 #

根据你的业务需求，有几种靠谱的方案：

1. 直接调整方法参数的泛型定义 #

如果你不需要在方法内部使用具体的T类型，完全可以把方法参数改成和目标变量一致的类型：

static void m(Consumer<List<? extends Number>> l) {
    Consumer<List<? extends Number>> l3 = l; // 编译通过
}

这是最直接、最安全的方式，从根源上消除了类型不匹配的问题。

2. 使用通配符拓宽方法参数的兼容性 #

如果必须保留T类型参数，可以把方法参数改成Consumer<? super List<T>>，这样就能兼容Consumer<List<? extends Number>>了：

static <T extends Number> void m(Consumer<? super List<T>> l) {
    Consumer<List<? extends Number>> l3 = (Consumer<List<? extends Number>>) l;
}

这里的强制类型转换是安全的，因为List<T>是List<? extends Number>的子类型，而Consumer<? super List<T>>包含了Consumer<List<? extends Number>>这个类型。

3. 通过辅助方法做类型捕获转换 #

如果需要保留方法原有的参数定义，还可以写一个泛型辅助方法来完成类型转换：

static <T extends Number> void m(Consumer<List<T>> l) {
    Consumer<List<? extends Number>> l3 = convert(l);
}

private static <T extends Number> Consumer<List<? extends Number>> convert(Consumer<List<T>> consumer) {
    return consumer::accept;
}

这个辅助方法利用了泛型的类型推断，让编译器确认转换的合法性，避免了直接强制转换的警告（当然，你得确保在调用l3时传入的List确实是List<T>类型，否则运行时可能会抛出类型转换异常）。

内容的提问来源于stack exchange，提问作者Artem Petrov