在Java泛型体系里，方法参数使用通配符是解决类型安全与代码复用矛盾的核心手段。很多初学者习惯把泛型类当作普通类一样传递，结果在编译期就收到类型不兼容的提示。要彻底弄明白方法参数中的通配符，必须先理解Java为什么不允许泛型协变，以及通配符在编译器层面做了哪些类型擦除与边界检查。
为什么普通泛型参数无法直接兼容子类型
Java的泛型在编译期会进行严格的类型检查，但运行时由于类型擦除，所有泛型实例都退化成原始类型。假设我们有一个方法定义为void printList(List<Object> list)，如果允许直接传入List<String>，那么在方法内部就可以通过list.add(new Integer(1))向其中放入非String对象。由于外部调用者认为它持有的是String集合，后续遍历时就会触发ClassCastException。因此编译器禁止这种协变传参，从而引出通配符机制。
通配符的本质是给泛型参数加一个未知但有边界的占位符。使用上界通配符List<? extends Number>时，编译器知道列表元素一定是Number或其子类，但不知道具体是Integer还是Double，所以禁止调用add方法（除了null）。反过来，下界通配符List<? super Integer>表示列表元素可能是Integer或它的任意父类，此时可以安全地写入Integer，但读取出来只能当作Object处理。这种限制不是缺陷，而是把类型错误从运行期提前到了编译期。
我们可以通过一段代码对比看出差异。下面这个方法试图接收任意数字列表并打印，若不使用通配符就会写死类型：
import java.util.List;
public class WildcardDemo {
// 错误写法：无法传入List<Integer>
public static void wrongPrint(List<Number> list) {
for (Number n : list) {
System.out.println(n);
}
}
// 正确写法：使用上界通配符
public static void rightPrint(List<? extends Number> list) {
for (Number n : list) {
System.out.println(n);
}
}
}
上界与下界通配符在方法参数中的实战选择
方法参数到底该用? extends T还是? super T，业界总结为PECS原则：Producer（生产者）用extends，Consumer（消费者）用super。如果一个方法只是从参数里读取数据然后向外提供，那参数就是生产者，应该用上界；如果一个方法是往参数里写入数据，那参数就是消费者，应该用下界。例如工具类Collections.copy的签名是copy(List<? super T> dest, List<? extends T> src)，src作为数据来源使用extends，dest作为数据去向使用super，完美体现了这一规则。
在实际业务里，我们经常需要写一个把配置项批量存入容器的函数。如果容器声明为List<? extends Config>，你无法向里面add任何具体的Config子类，因为编译器不确定列表的真实类型。但如果声明为List<? super AppConfig>，就可以放心add(new AppConfig())，因为无论列表是AppConfig还是其父类Config、Object，都能容纳AppConfig实例。下面的例子演示了下界通配符的安全写入：
import java.util.ArrayList;
import java.util.List;
class Config {}
class AppConfig extends Config {}
public class SuperDemo {
public static void fill(List<? super AppConfig> list) {
list.add(new AppConfig());
list.add(new AppConfig());
}
public static void main(String[] args) {
List<Config> configs = new ArrayList<>();
fill(configs);
System.out.println(configs.size());
}
}
无界通配符?通常用于方法逻辑完全不依赖元素具体类型的场景，比如判断集合是否为空、清空集合、计算hashCode等。此时参数写成List<?>即可，但注意不能对其元素做除Object外的任何假设。滥用无界通配符会让代码失去类型信息，所以仅在确有必要的时候使用。
通配符带来的类型推断陷阱与规避方案
虽然通配符提升了API灵活性，但在泛型方法调用时可能引发类型推断失败。例如一个泛型方法<T> T pick(List<T> list)，如果传入List<? extends Number>，编译器无法推断出具体的T，只能得到Number或编译错误。此时可以借助辅助方法或显式类型参数来引导编译器，或者使用有界类型参数代替通配符，例如把方法定义为<T extends Number> void handle(List<T> list)，既保留了子类型约束，又让T在具体逻辑中可用。
另一个常见陷阱是通配符嵌套，比如List<? extends List<? extends Number>>，这种写法虽然合法但可读性极差，且容易在遍历时陷入多层类型未知。建议在方法参数设计中尽量压平结构，或借助自定义泛型接口隐藏复杂通配符。如果必须暴露，应在方法注释中明确说明每个层级的边界含义，避免调用方误用。
最后要注意，通配符只影响编译期检查，运行期由于类型擦除，所有? extends X和? super X都变成原始边界。因此不要试图用instanceof去判断通配符代表的真实类型，而应该在设计阶段就通过合理的上界下界划分，让类型安全由编译器保障。掌握这些细节后，Java方法参数里的通配符将从令人困惑的语法糖，变成写出健壮通用API的利器。