1. 从一个编译报错说起：为什么你的泛型代码总是不通过写了几年Java的人，几乎都遇到过这样一种情况：代码逻辑明明没问题，IDE却给你标了一堆红，编译器报的错还特别抽象，比如"incompatible types: List cannot be converted to List "。你盯着屏幕想，Dog明明是Animal的子类，凭什么List 就不能当List 用？这不是天经地义的事吗？这个问题背后牵扯出来的，就是Java泛型系统里最容易被忽视、但在实际开发中又绕不开的两个核心概念：协变（Covariance）与逆变（Contravariance），以及泛型的上下边界通配符——? extends T和? super T。很多朋友写业务代码时，用泛型基本停留在List<String>、Map<String, Object>这种层面，一旦涉及到泛型之间的类型转换、方法参数设计、框架源码阅读，就会卡住。比如你去看Java标准库里的Collections.copy方法签名，或者Spring里的一些泛型工具类，满屏的? extends和? super，第一反应就是"这写的什么玩意儿"。这篇内容就是来解决这个问题的。我会从类型系统的底层逻辑出发，把协变、逆变、不变这几个概念讲清楚，然后把extends和super这两个通配符边界的使用场景、设计意图、常见坑点全部拆开揉碎。不管你是刚接触泛型的新手，还是写了几年代码但对这块一直模棱两可的老手，看完之后应该都能有一个清晰的心智模型。需要说明的是，这篇文章不会只停留在"语法层面告诉你这么写能编译通过"，而是会重点解释为什么Java要这么设计，以及在实际项目里怎么用这套规则写出更安全、更灵活的代码。毕竟，知道怎么用和知道为什么这么用，是两回事。2. 类型系统的底层逻辑：协变、逆变与不变到底是什么2.1 用生活场景理解三个核心概念先抛开Java代码，用一个现实中的例子来建立直觉。假设我们有一个分类体系：水果 → 苹果 → 红富士苹果。这是一个典型的继承链，红富士是苹果的一种，苹果是水果的一种。现在考虑一个"容器"的概念，比如一个果篮。问题来了：如果我把"一篮苹果"看作"一篮水果"，这合理吗？从直觉上说，好像合理，因为苹果本来就是水果。但从操作安全性上说，就有问题了——如果"一篮苹果"可以被当作"一篮水果"来用，那我往里面放一个香蕉行不行？逻辑上它是"一篮水果"，放香蕉应该可以，但实际上这个篮子只能装苹果，放香蕉就出事了。这就是类型系统里最核心的矛盾：子类型关系能否安全地传递到容器类型上。三个术语分别对应三种不同的传递规则：协变（Covariance）：如果A是B的子类型，那么Container<A>也是Container<B>的子类型。方向一致，所以叫"协"变。数组在Java里就是协变的——Apple[]是Fruit[]的子类型。逆变（Contravariance）：如果A是B的子类型，那么Container<B>是Container<A>的子类型。方向反过来了，所以叫"逆"变。不变（Invariance）：不管A和B什么关系，Container<A>和Container<B>之间没有任何子类型关系。Java的泛型默认就是不变的。用一句话总结：协变是"顺着继承方向走"，逆变是"逆着继承方向走"，不变是"各走各的，互不相干"。2.2 为什么Java泛型默认是不变的这个问题很关键，理解了它，后面所有的设计就都顺了。Java的泛型被设计成默认不变，根本原因是类型安全。我们来看一段假设泛型是协变的代码（注意，这段代码在Java里编译不过，只是用来演示逻辑）：// 假设Java允许这样写（实际上不允许） List<Apple> apples = new ArrayList<>(); List<Fruit> fruits = apples; // 假设协变成立 fruits.add(new Banana()); // 编译通过，因为Banana是Fruit Apple a = apples.get(0); // 运行时炸了，取出来的是Banana如果泛型是协变的，那么List<Apple>就能赋给List<Fruit>，然后你就可以往里面塞任何Fruit的子类。但实际底层数组还是Apple类型的，塞进去一个Banana，运行时就会抛ClassCastException或者ArrayStoreException。Java的设计者选择了在编译期就杜绝这种可能性，所以泛型默认不变。List<Apple>和List<Fruit>就是两个完全不同的类型，没有任何赋值兼容性。这个决定牺牲了一部分灵活性，但换来了编译期的类型安全。注意：数组是协变的，这是Java早期设计的一个历史遗留问题。Apple[]可以赋给Fruit[]，但运行时如果塞错类型会抛ArrayStoreException。这也是为什么Effective Java里建议优先使用List而不是数组的原因之一。2.3 通配符的引入：在不变的基础上找回灵活性泛型不变虽然安全，但太死板了。很多时候我们确实需要"接受一个Fruit的任意子类型的列表"这种语义。于是Java引入了通配符（Wildcard），用?来表示"某种未知类型"，再配合extends和super来限定这个未知类型的范围。? extends T：表示类型是T或T的某个子类型，上界是T。这叫上边界通配符。? super T：表示类型是T或T的某个父类型，下界是T。这叫下边界通配符。?：无界通配符，等价于? extends Object。这两个通配符就是Java在不变的基础上，为特定使用场景提供的"受控协变"和"受控逆变"。注意关键词——受控。它们不是让泛型真的变成协变或逆变，而是在读写操作上做了精细的权限控制。3. extends与super的读写权限：PECS原则的来龙去脉3.1 上边界extends：只能读，不能写先看? extends T的实际行为。假设我们有一个方法：public static double sumOfList(List<? extends Number> list) { double sum = 0; for (Number n : list) { sum += n.doubleValue(); } return sum; }这个方法可以接受List<Integer>、List<Double>、List<Long>等任何Number子类型的列表。在方法内部，你可以遍历、可以读取元素，读出来的元素类型至少是Number，所以调用doubleValue()是安全的。但你不能往里面写：public static void addToList(List<? extends Number> list) { list.add(1); // 编译错误 list.add(1.0); // 编译错误 list.add(null); // 只有null可以 }为什么不能写？因为编译器不知道这个?到底代表什么具体类型。它可能是List<Integer>，也可能是List<Double>。如果你能往里加Integer，那万一实际是List<Double>呢？类型就崩了。所以编译器干脆一刀切：上边界通配符的集合，只能读不能写（除了null）。从类型安全的角度看，这个限制是必然的。读取的时候，我们知道元素至少是Number，所以能安全地当作Number用；写入的时候，我们不知道具体是哪个子类型，所以任何写入都可能不安全。3.2 下边界super：只能写，读出来只能是Object再看? super T：public static void addNumbers(List<? super Integer> list) { list.add(1); list.add(2); list.add(3); }这个方法可以接受List<Integer>、List<Number>、List<Object>。在方法内部，你可以往里面添加Integer（以及Integer的子类），因为不管实际类型是这三个中的哪一个，Integer都能安全地放进去。但读取的时候就有问题了：public static void readFromList(List<? super Integer> list) { Object obj = list.get(0); // 只能赋给Object Integer i = list.get(0); // 编译错误 }为什么只能读成Object？因为编译器不知道这个?到底是Integer、Number还是Object。唯一能确定的是，它一定是Object的子类型，所以只能保证读出来是Object。3.3 PECS原则：Producer Extends, Consumer Super把上面的规则总结一下，就得到了Joshua Bloch在Effective Java里提出的PECS原则：如果一个容器是生产者（你主要从里面读数据），用? extends T。如果一个容器是消费者（你主要往里面写数据），用? super T。如果既要读又要写，那就别用通配符，老老实实用具体类型。这个原则不是死记硬背的口诀，而是从读写权限推导出来的必然结论。我见过很多朋友背下了PECS，但遇到具体场景还是不知道怎么选，根本原因就是没理解"读安全"和"写安全"这两个约束是怎么来的。用一个表格把读写权限对比清楚：通配符形式能否读取读出的类型能否写入可写入的类型List<? extends Number>可以Number或其子类不可以仅nullList<? super Integer>可以Object可以Integer及其子类List<?>可以Object不可以仅nullList<Number>可以Number可以Number及其子类这张表建议存下来，写代码拿不准的时候对照一下，比翻文档快得多。4. 实战场景拆解：什么时候该用extends，什么时候该用super4.1 场景一：设计通用的数据统计方法假设你在做一个数据分析模块，需要对各种数值类型的集合求和。这时候方法参数应该用? extends Number：public class Statistics { public static double average(List<? extends Number> data) { if (data.isEmpty()) { throw new IllegalArgumentException("数据不能为空"); } double sum = 0; for (Number n : data) { sum += n.doubleValue(); } return sum / data.size(); } }调用方可以传List<Integer>、List<Double>、List<BigDecimal>，都能正常工作。这里方法只读取数据，不写入，所以用extends是正确且安全的。如果你把参数写成List<Number>，那调用方就必须把数据先转成List<Number>才能传进来，非常别扭。这就是通配符带来的灵活性价值。4.2 场景二：设计一个通用的数据收集器反过来，如果你要设计一个往集合里批量添加数据的方法，就应该用? super T：public class DataCollector { public static void collect(List<? super Integer> target, int count) { for (int i = 0; i < count; i++) { target.add(i); } } }调用方可以传List<Integer>、List<Number>、List<Object>，都能接收。方法内部只写入不读取，所以用super是安全的。这个设计在实际中很有用。比如你有一个List<Number>想收集各种数值计算结果，或者有一个List<Object>想收集任意类型的数据，都可以复用这个方法。4.3 场景三：同时读写时该怎么办有些场景下，一个方法既要读又要写。比如一个"复制"操作：public static <T> void copy(List<? super T> dest, List<? extends T> src) { for (T item : src) { dest.add(item); } }这是Java标准库Collections.copy的签名简化版。注意这里用了两个不同的通配符：源列表用? extends T（只读），目标列表用? super T（只写）。这样设计之后，调用非常灵活：List<Number> dest = new ArrayList<>(); List<Integer> src = Arrays.asList(1, 2, 3); copy(dest, src); // 完全合法如果不用通配符，写成copy(List<T> dest, List<T> src)，那List<Number>和List<Integer>就没法一起用了，必须类型完全一致。这就是通配符在API设计中的威力。4.4 场景四：泛型方法的类型参数推断再来看一个稍微复杂一点的场景，涉及泛型方法的类型推断：public static <T> T max(List<? extends T> list, Comparator<? super T> comparator) { T max = list.get(0); for (T item : list) { if (comparator.compare(item, max) > 0) { max = item; } } return max; }这个方法的设计非常经典：列表用? extends T（因为要读取元素），比较器用? super T（因为比较器是消费者，它"消费"两个T来产生比较结果）。调用的时候：List<Integer> numbers = Arrays.asList(3, 1, 4, 1, 5); Comparator<Number> numberComparator = Comparator.comparingDouble(Number::doubleValue); Integer max = max(numbers, numberComparator);List<Integer>匹配? extends Integer，Comparator<Number>匹配? super Integer，类型推断正常工作。如果比较器写成Comparator<Integer>当然也行，但用Comparator<Number>更通用，能复用于更多场景。5. 类型擦除带来的限制与坑点排查5.1 类型擦除：泛型信息在运行时不存在要真正理解通配符的边界，绕不开**类型擦除（Type Erasure）**这个概念。Java的泛型是编译期特性，编译完成后，所有的泛型信息都会被擦除。List<Integer>和List<String>在运行时都是List，元素类型信息丢失了。这带来几个直接后果：第一，你不能用instanceof判断泛型类型：List<Integer> list = new ArrayList<>(); if (list instanceof List<Integer>) { } // 编译错误 if (list instanceof List<?>) { } // 这样可以第二，你不能创建泛型数组：List<Integer>[] array = new List<Integer>[10]; // 编译错误第三，你不能在静态上下文使用类的类型参数：public class Box<T> { private static T instance; // 编译错误 }理解类型擦除之后，很多通配符的限制就变得理所当然了。编译器在编译期能拿到的类型信息有限，所以它必须采取保守策略，宁可拒绝一些理论上安全的操作，也不放过任何可能不安全的操作。5.2 常见编译错误速查下面这张表整理了使用通配符时最常见的编译错误和原因：错误信息典型代码根本原因解决方案incompatible typesList<Dog> d = new ArrayList<Animal>();泛型不变用通配符或调整类型cannot be convertedList<Animal> a = dogList;泛型不变用? extends Animaladd cannot be appliedlist.add(x)其中list是List<? extends T>上边界不能写改用List<? super T>incompatible types: ObjectT t = list.get(0)其中list是List<? super T>下边界只能读Object明确类型或调整设计non-static type variable静态方法用类泛型参数类型擦除方法自己声明泛型参数5.3 一个真实的踩坑案例我之前在一个数据处理项目里遇到过这样一个问题。有一个方法需要接收一个集合，然后往里面填充数据，同时还要读取已有数据做去重判断。最初的签名是这样的：public static void process(List<? extends Number> data) { // 读取没问题 for (Number n : data) { // 做一些处理 } // 但这里想往里面加数据就炸了 data.add(100); // 编译错误 }当时的直觉是"我传进来的就是List ，为什么不能加"。但编译器不管这些，它只认? extends Number这个声明，在这个声明下，写入操作一律禁止。后来改成了两个方案。方案一是把参数改成List<Number>，牺牲了接受List<Integer>的灵活性。方案二是拆成两个方法，一个负责读，一个负责写。最终选择了方案二，因为调用方确实有传List<Integer>的需求：public static double readAndSum(List<? extends Number> data) { double sum = 0; for (Number n : data) { sum += n.doubleValue(); } return sum; } public static void fillData(List<? super Integer> target, int count) { for (int i = 0; i < count; i++) { target.add(i); } }这个案例的教训是：通配符的选择不是看调用方传什么，而是看方法内部怎么用。方法内部只读，就用extends；只写，就用super；既读又写，就别用通配符。提示：如果你发现一个方法既需要读又需要写，而且调用方还需要传各种子类型，那通常说明这个方法承担了太多职责，应该考虑拆分。这是设计层面的信号，不只是语法问题。6. 从源码看设计：标准库和框架里的通配符实践6.1 Collections工具类的经典设计Java标准库的java.util.Collections类是学习通配符的最佳教材。我们来看几个典型方法：public static <T extends Comparable<? super T>> void sort(List<T> list)这个签名信息量很大。T extends Comparable<? super T>的意思是：T必须实现Comparable接口，而且这个Comparable的比较对象类型是T或T的父类型。为什么要用? super T？因为如果有一个类Student implements Comparable<Person>，那么Student对象可以和Person比较，这是合理的。用? super T让这种设计成为可能。public static <T> void fill(List<? super T> list, T obj)fill方法是往列表里填充元素，典型的消费者场景，所以用? super T。这样List<Object>也能被填充Integer，非常灵活。public static <T> T max(Collection<? extends T> coll, Comparator<? super T> comp)max方法同时用到了两种通配符：集合是生产者用extends，比较器是消费者用super。这个签名值得反复品味，它把PECS原则体现得淋漓尽致。6.2 Stream API中的通配符Java 8引入的Stream API也大量使用了通配符。比如：Stream<T> filter(Predicate<? super T> predicate); <R> Stream<R> map(Function<? super T, ? extends R> mapper);filter接收一个Predicate<? super T>，因为Predicate是消费者——它消费一个T，返回boolean。用? super T意味着你可以传一个能处理T的父类型的Predicate，更通用。map接收Function<? super T, ? extends R>，输入是消费者（消费T），输出是生产者（产生R）。所以输入用? super T，输出用? extends R。这个设计让Stream的链式操作非常灵活，比如你可以用一个Function<Object, String>来处理Stream<Integer>。6.3 自己设计API时的通配符决策流程看了这么多源码，可以总结出一个设计API时的决策流程：第一步，问自己这个方法主要是读还是写。如果只读，考虑? extends T；如果只写，考虑? super T。第二步，问自己调用方是否真的需要传子类型。如果调用方永远只传精确类型，那用具体类型更简单清晰，不必强行上通配符。第三步，考虑API的长期演进。通配符会让签名更复杂，但换来更好的扩展性。如果是内部工具方法，简单优先；如果是公共API，灵活性优先。第四步，写测试验证。用不同层次的类型去调用，看看是否都能编译通过，行为是否符合预期。这里有一个我个人的经验：不要为了炫技而用通配符。我见过一些代码，明明调用方只传一种类型，方法签名却写得极其复杂，满屏的? extends和? super，维护成本很高。通配符是工具，不是目的，用在该用的地方就行。7. 进阶话题：自限定类型与递归泛型边界7.1 什么是自限定类型在阅读一些框架源码时，你可能会看到这样的签名：public class Builder<T extends Builder<T>> { public T withName(String name) { // ... return (T) this; } }T extends Builder<T>这种写法叫自限定类型（Self-Bounded Type），或者叫递归泛型边界。它的作用是让父类的方法返回子类的类型，从而支持流畅的链式调用。这个模式在构建器（Builder）模式中很常见。如果不这么写，父类的withName方法只能返回Builder，子类调用后就丢失了子类型信息，没法继续调用子类特有的方法。用了自限定类型之后，子类继承时把T指定为自己，父类方法就能返回子类类型了。7.2 递归边界的编译期检查自限定类型还有一个副作用：它能在编译期强制约束继承关系。比如：public abstract class Enum<E extends Enum<E>> { // ... }这是Java标准库中Enum类的签名。E extends Enum<E>意味着任何继承Enum的类，都必须把自己作为类型参数传进去。这种设计保证了枚举类型之间的比较是类型安全的。理解这个模式需要一点抽象思维，但核心逻辑不复杂：用类型参数来表示"子类自己"，从而让父类能够引用子类的类型。这是泛型边界的一个高级应用，日常业务代码用得不多，但读框架源码时经常遇到。7.3 通配符捕获与辅助方法有时候编译器无法直接推断通配符的具体类型，需要借助辅助方法来"捕获"类型。看这个例子：public static void swap(List<?> list, int i, int j) { // list.set(i, list.get(j)); // 编译错误 swapHelper(list, i, j); } private static <T> void swapHelper(List<T> list, int i, int j) { T temp = list.get(i); list.set(i, list.get(j)); list.set(j, temp); }List<?>既不能读成具体类型也不能写，直接操作会编译失败。但通过一个泛型辅助方法swapHelper，编译器可以捕获通配符为具体类型T，然后在辅助方法内部正常读写。这个技巧叫通配符捕获（Wildcard Capture），是处理无界通配符时的常用手段。这个模式在实际中不算常见，但当你需要对List<?>做写操作时，它是标准解法。记住这个套路，遇到类似问题时能省不少时间。8. 实操心得与避坑清单8.1 我踩过的几个典型坑坑一：以为List<Object>能接收一切。刚学泛型的时候，总觉得List<Object>是万能的，什么都能往里放。实际上List<Object>和List<String>之间没有任何赋值关系，List<String>不能赋给List<Object>。要接收各种类型的列表，得用List<?>或者List<? extends Object>。坑二：在extends通配符上调用add。这个前面说过了，但实际写代码时还是容易忘。特别是方法参数声明和实际传入类型不一致的时候，直觉上觉得"我传的就是List ，加个Integer怎么了"，但编译器只看声明。坑三：混淆? extends T和<T extends X>。这两个语法长得像，含义完全不同。? extends T是通配符边界，用在类型使用的位置；<T extends X>是类型参数声明，用在方法或类的定义上。前者是"某种未知的T子类型"，后者是"一个名为T的类型参数，它必须是X的子类型"。坑四：在返回值上用通配符。有些朋友会在方法返回值上写List<? extends Number>，这通常是个坏设计。因为调用方拿到这个返回值后，既不能读成具体类型（只能读成Number），也不能写，非常受限。返回值应该尽量用具体类型，把灵活性留给参数。8.2 通配符使用检查清单写泛型代码时，可以对照这个清单快速检查：方法参数是只读的吗？是的话考虑? extends T。方法参数是只写的吗？是的话考虑? super T。方法参数既读又写吗？是的话用具体类型，别用通配符。返回值上用了通配符吗？如果是，重新考虑设计。调用方需要传子类型吗？不需要的话，用具体类型更清晰。类型参数和通配符分清楚了吗？<T>是声明，<?>是使用。8.3 关于可读性的个人建议最后说一点关于代码可读性的体会。通配符虽然强大，但过度使用会让代码变得难以理解。我的原则是：如果一个方法签名需要超过两行才能写完，或者需要注释才能解释清楚，那就说明设计可能过于复杂了。在实际项目中，大部分业务代码用不到复杂的通配符。真正需要精细控制泛型边界的地方，通常是基础设施代码、工具类、框架扩展点。这些地方值得花时间把通配符用对，因为它们的复用率高，影响面大。而普通的业务逻辑，用具体类型反而更清晰、更好维护。另外，IDE的类型提示功能现在做得很好了，拿不准的时候把鼠标悬停在方法上，看看推断出来的类型是什么，往往能快速定位问题。我调试泛型问题时，经常用这招来确认编译器到底把?推断成了什么类型。如果这篇文章只能记住一句话，那就是：extends管读，super管写，读写都要就别用通配符。把这句话刻在脑子里，90%的泛型边界问题都能迎刃而解。剩下的10%，等你真正遇到的时候，再回来翻翻PECS原则和类型擦除那两节，基本就够用了。
1. 从一个编译报错说起：为什么你的泛型代码总是不通过写了几年Java的人，几乎都遇到过这样一种情况：代码逻辑明明没问题，IDE却给你标了一堆红，编译器报的错还特别抽象，比如"incompatible types: List cannot be converted to List "。你盯着屏幕想，Dog明明是Animal的子类，凭什么List 就不能当List 用？这不是天经地义的事吗？这个问题背后牵扯出来的，就是Java泛型系统里最容易被忽视、但在实际开发中又绕不开的两个核心概念：协变（Covariance）与逆变（Contravariance），以及泛型的上下边界通配符——? extends T和? super T。很多朋友写业务代码时，用泛型基本停留在List<String>、Map<String, Object>这种层面，一旦涉及到泛型之间的类型转换、方法参数设计、框架源码阅读，就会卡住。比如你去看Java标准库里的Collections.copy方法签名，或者Spring里的一些泛型工具类，满屏的? extends和? super，第一反应就是"这写的什么玩意儿"。这篇内容就是来解决这个问题的。我会从类型系统的底层逻辑出发，把协变、逆变、不变这几个概念讲清楚，然后把extends和super这两个通配符边界的使用场景、设计意图、常见坑点全部拆开揉碎。不管你是刚接触泛型的新手，还是写了几年代码但对这块一直模棱两可的老手，看完之后应该都能有一个清晰的心智模型。需要说明的是，这篇文章不会只停留在"语法层面告诉你这么写能编译通过"，而是会重点解释为什么Java要这么设计，以及在实际项目里怎么用这套规则写出更安全、更灵活的代码。毕竟，知道怎么用和知道为什么这么用，是两回事。2. 类型系统的底层逻辑：协变、逆变与不变到底是什么2.1 用生活场景理解三个核心概念先抛开Java代码，用一个现实中的例子来建立直觉。假设我们有一个分类体系：水果 → 苹果 → 红富士苹果。这是一个典型的继承链，红富士是苹果的一种，苹果是水果的一种。现在考虑一个"容器"的概念，比如一个果篮。问题来了：如果我把"一篮苹果"看作"一篮水果"，这合理吗？从直觉上说，好像合理，因为苹果本来就是水果。但从操作安全性上说，就有问题了——如果"一篮苹果"可以被当作"一篮水果"来用，那我往里面放一个香蕉行不行？逻辑上它是"一篮水果"，放香蕉应该可以，但实际上这个篮子只能装苹果，放香蕉就出事了。这就是类型系统里最核心的矛盾：子类型关系能否安全地传递到容器类型上。三个术语分别对应三种不同的传递规则：协变（Covariance）：如果A是B的子类型，那么Container<A>也是Container<B>的子类型。方向一致，所以叫"协"变。数组在Java里就是协变的——Apple[]是Fruit[]的子类型。逆变（Contravariance）：如果A是B的子类型，那么Container<B>是Container<A>的子类型。方向反过来了，所以叫"逆"变。不变（Invariance）：不管A和B什么关系，Container<A>和Container<B>之间没有任何子类型关系。Java的泛型默认就是不变的。用一句话总结：协变是"顺着继承方向走"，逆变是"逆着继承方向走"，不变是"各走各的，互不相干"。2.2 为什么Java泛型默认是不变的这个问题很关键，理解了它，后面所有的设计就都顺了。Java的泛型被设计成默认不变，根本原因是类型安全。我们来看一段假设泛型是协变的代码（注意，这段代码在Java里编译不过，只是用来演示逻辑）：// 假设Java允许这样写（实际上不允许） List<Apple> apples = new ArrayList<>(); List<Fruit> fruits = apples; // 假设协变成立 fruits.add(new Banana()); // 编译通过，因为Banana是Fruit Apple a = apples.get(0); // 运行时炸了，取出来的是Banana如果泛型是协变的，那么List<Apple>就能赋给List<Fruit>，然后你就可以往里面塞任何Fruit的子类。但实际底层数组还是Apple类型的，塞进去一个Banana，运行时就会抛ClassCastException或者ArrayStoreException。Java的设计者选择了在编译期就杜绝这种可能性，所以泛型默认不变。List<Apple>和List<Fruit>就是两个完全不同的类型，没有任何赋值兼容性。这个决定牺牲了一部分灵活性，但换来了编译期的类型安全。注意：数组是协变的，这是Java早期设计的一个历史遗留问题。Apple[]可以赋给Fruit[]，但运行时如果塞错类型会抛ArrayStoreException。这也是为什么Effective Java里建议优先使用List而不是数组的原因之一。2.3 通配符的引入：在不变的基础上找回灵活性泛型不变虽然安全，但太死板了。很多时候我们确实需要"接受一个Fruit的任意子类型的列表"这种语义。于是Java引入了通配符（Wildcard），用?来表示"某种未知类型"，再配合extends和super来限定这个未知类型的范围。? extends T：表示类型是T或T的某个子类型，上界是T。这叫上边界通配符。? super T：表示类型是T或T的某个父类型，下界是T。这叫下边界通配符。?：无界通配符，等价于? extends Object。这两个通配符就是Java在不变的基础上，为特定使用场景提供的"受控协变"和"受控逆变"。注意关键词——受控。它们不是让泛型真的变成协变或逆变，而是在读写操作上做了精细的权限控制。3. extends与super的读写权限：PECS原则的来龙去脉3.1 上边界extends：只能读，不能写先看? extends T的实际行为。假设我们有一个方法：public static double sumOfList(List<? extends Number> list) { double sum = 0; for (Number n : list) { sum += n.doubleValue(); } return sum; }这个方法可以接受List<Integer>、List<Double>、List<Long>等任何Number子类型的列表。在方法内部，你可以遍历、可以读取元素，读出来的元素类型至少是Number，所以调用doubleValue()是安全的。但你不能往里面写：public static void addToList(List<? extends Number> list) { list.add(1); // 编译错误 list.add(1.0); // 编译错误 list.add(null); // 只有null可以 }为什么不能写？因为编译器不知道这个?到底代表什么具体类型。它可能是List<Integer>，也可能是List<Double>。如果你能往里加Integer，那万一实际是List<Double>呢？类型就崩了。所以编译器干脆一刀切：上边界通配符的集合，只能读不能写（除了null）。从类型安全的角度看，这个限制是必然的。读取的时候，我们知道元素至少是Number，所以能安全地当作Number用；写入的时候，我们不知道具体是哪个子类型，所以任何写入都可能不安全。3.2 下边界super：只能写，读出来只能是Object再看? super T：public static void addNumbers(List<? super Integer> list) { list.add(1); list.add(2); list.add(3); }这个方法可以接受List<Integer>、List<Number>、List<Object>。在方法内部，你可以往里面添加Integer（以及Integer的子类），因为不管实际类型是这三个中的哪一个，Integer都能安全地放进去。但读取的时候就有问题了：public static void readFromList(List<? super Integer> list) { Object obj = list.get(0); // 只能赋给Object Integer i = list.get(0); // 编译错误 }为什么只能读成Object？因为编译器不知道这个?到底是Integer、Number还是Object。唯一能确定的是，它一定是Object的子类型，所以只能保证读出来是Object。3.3 PECS原则：Producer Extends, Consumer Super把上面的规则总结一下，就得到了Joshua Bloch在Effective Java里提出的PECS原则：如果一个容器是生产者（你主要从里面读数据），用? extends T。如果一个容器是消费者（你主要往里面写数据），用? super T。如果既要读又要写，那就别用通配符，老老实实用具体类型。这个原则不是死记硬背的口诀，而是从读写权限推导出来的必然结论。我见过很多朋友背下了PECS，但遇到具体场景还是不知道怎么选，根本原因就是没理解"读安全"和"写安全"这两个约束是怎么来的。用一个表格把读写权限对比清楚：通配符形式能否读取读出的类型能否写入可写入的类型List<? extends Number>可以Number或其子类不可以仅nullList<? super Integer>可以Object可以Integer及其子类List<?>可以Object不可以仅nullList<Number>可以Number可以Number及其子类这张表建议存下来，写代码拿不准的时候对照一下，比翻文档快得多。4. 实战场景拆解：什么时候该用extends，什么时候该用super4.1 场景一：设计通用的数据统计方法假设你在做一个数据分析模块，需要对各种数值类型的集合求和。这时候方法参数应该用? extends Number：public class Statistics { public static double average(List<? extends Number> data) { if (data.isEmpty()) { throw new IllegalArgumentException("数据不能为空"); } double sum = 0; for (Number n : data) { sum += n.doubleValue(); } return sum / data.size(); } }调用方可以传List<Integer>、List<Double>、List<BigDecimal>，都能正常工作。这里方法只读取数据，不写入，所以用extends是正确且安全的。如果你把参数写成List<Number>，那调用方就必须把数据先转成List<Number>才能传进来，非常别扭。这就是通配符带来的灵活性价值。4.2 场景二：设计一个通用的数据收集器反过来，如果你要设计一个往集合里批量添加数据的方法，就应该用? super T：public class DataCollector { public static void collect(List<? super Integer> target, int count) { for (int i = 0; i < count; i++) { target.add(i); } } }调用方可以传List<Integer>、List<Number>、List<Object>，都能接收。方法内部只写入不读取，所以用super是安全的。这个设计在实际中很有用。比如你有一个List<Number>想收集各种数值计算结果，或者有一个List<Object>想收集任意类型的数据，都可以复用这个方法。4.3 场景三：同时读写时该怎么办有些场景下，一个方法既要读又要写。比如一个"复制"操作：public static <T> void copy(List<? super T> dest, List<? extends T> src) { for (T item : src) { dest.add(item); } }这是Java标准库Collections.copy的签名简化版。注意这里用了两个不同的通配符：源列表用? extends T（只读），目标列表用? super T（只写）。这样设计之后，调用非常灵活：List<Number> dest = new ArrayList<>(); List<Integer> src = Arrays.asList(1, 2, 3); copy(dest, src); // 完全合法如果不用通配符，写成copy(List<T> dest, List<T> src)，那List<Number>和List<Integer>就没法一起用了，必须类型完全一致。这就是通配符在API设计中的威力。4.4 场景四：泛型方法的类型参数推断再来看一个稍微复杂一点的场景，涉及泛型方法的类型推断：public static <T> T max(List<? extends T> list, Comparator<? super T> comparator) { T max = list.get(0); for (T item : list) { if (comparator.compare(item, max) > 0) { max = item; } } return max; }这个方法的设计非常经典：列表用? extends T（因为要读取元素），比较器用? super T（因为比较器是消费者，它"消费"两个T来产生比较结果）。调用的时候：List<Integer> numbers = Arrays.asList(3, 1, 4, 1, 5); Comparator<Number> numberComparator = Comparator.comparingDouble(Number::doubleValue); Integer max = max(numbers, numberComparator);List<Integer>匹配? extends Integer，Comparator<Number>匹配? super Integer，类型推断正常工作。如果比较器写成Comparator<Integer>当然也行，但用Comparator<Number>更通用，能复用于更多场景。5. 类型擦除带来的限制与坑点排查5.1 类型擦除：泛型信息在运行时不存在要真正理解通配符的边界，绕不开**类型擦除（Type Erasure）**这个概念。Java的泛型是编译期特性，编译完成后，所有的泛型信息都会被擦除。List<Integer>和List<String>在运行时都是List，元素类型信息丢失了。这带来几个直接后果：第一，你不能用instanceof判断泛型类型：List<Integer> list = new ArrayList<>(); if (list instanceof List<Integer>) { } // 编译错误 if (list instanceof List<?>) { } // 这样可以第二，你不能创建泛型数组：List<Integer>[] array = new List<Integer>[10]; // 编译错误第三，你不能在静态上下文使用类的类型参数：public class Box<T> { private static T instance; // 编译错误 }理解类型擦除之后，很多通配符的限制就变得理所当然了。编译器在编译期能拿到的类型信息有限，所以它必须采取保守策略，宁可拒绝一些理论上安全的操作，也不放过任何可能不安全的操作。5.2 常见编译错误速查下面这张表整理了使用通配符时最常见的编译错误和原因：错误信息典型代码根本原因解决方案incompatible typesList<Dog> d = new ArrayList<Animal>();泛型不变用通配符或调整类型cannot be convertedList<Animal> a = dogList;泛型不变用? extends Animaladd cannot be appliedlist.add(x)其中list是List<? extends T>上边界不能写改用List<? super T>incompatible types: ObjectT t = list.get(0)其中list是List<? super T>下边界只能读Object明确类型或调整设计non-static type variable静态方法用类泛型参数类型擦除方法自己声明泛型参数5.3 一个真实的踩坑案例我之前在一个数据处理项目里遇到过这样一个问题。有一个方法需要接收一个集合，然后往里面填充数据，同时还要读取已有数据做去重判断。最初的签名是这样的：public static void process(List<? extends Number> data) { // 读取没问题 for (Number n : data) { // 做一些处理 } // 但这里想往里面加数据就炸了 data.add(100); // 编译错误 }当时的直觉是"我传进来的就是List ，为什么不能加"。但编译器不管这些，它只认? extends Number这个声明，在这个声明下，写入操作一律禁止。后来改成了两个方案。方案一是把参数改成List<Number>，牺牲了接受List<Integer>的灵活性。方案二是拆成两个方法，一个负责读，一个负责写。最终选择了方案二，因为调用方确实有传List<Integer>的需求：public static double readAndSum(List<? extends Number> data) { double sum = 0; for (Number n : data) { sum += n.doubleValue(); } return sum; } public static void fillData(List<? super Integer> target, int count) { for (int i = 0; i < count; i++) { target.add(i); } }这个案例的教训是：通配符的选择不是看调用方传什么，而是看方法内部怎么用。方法内部只读，就用extends；只写，就用super；既读又写，就别用通配符。提示：如果你发现一个方法既需要读又需要写，而且调用方还需要传各种子类型，那通常说明这个方法承担了太多职责，应该考虑拆分。这是设计层面的信号，不只是语法问题。6. 从源码看设计：标准库和框架里的通配符实践6.1 Collections工具类的经典设计Java标准库的java.util.Collections类是学习通配符的最佳教材。我们来看几个典型方法：public static <T extends Comparable<? super T>> void sort(List<T> list)这个签名信息量很大。T extends Comparable<? super T>的意思是：T必须实现Comparable接口，而且这个Comparable的比较对象类型是T或T的父类型。为什么要用? super T？因为如果有一个类Student implements Comparable<Person>，那么Student对象可以和Person比较，这是合理的。用? super T让这种设计成为可能。public static <T> void fill(List<? super T> list, T obj)fill方法是往列表里填充元素，典型的消费者场景，所以用? super T。这样List<Object>也能被填充Integer，非常灵活。public static <T> T max(Collection<? extends T> coll, Comparator<? super T> comp)max方法同时用到了两种通配符：集合是生产者用extends，比较器是消费者用super。这个签名值得反复品味，它把PECS原则体现得淋漓尽致。6.2 Stream API中的通配符Java 8引入的Stream API也大量使用了通配符。比如：Stream<T> filter(Predicate<? super T> predicate); <R> Stream<R> map(Function<? super T, ? extends R> mapper);filter接收一个Predicate<? super T>，因为Predicate是消费者——它消费一个T，返回boolean。用? super T意味着你可以传一个能处理T的父类型的Predicate，更通用。map接收Function<? super T, ? extends R>，输入是消费者（消费T），输出是生产者（产生R）。所以输入用? super T，输出用? extends R。这个设计让Stream的链式操作非常灵活，比如你可以用一个Function<Object, String>来处理Stream<Integer>。6.3 自己设计API时的通配符决策流程看了这么多源码，可以总结出一个设计API时的决策流程：第一步，问自己这个方法主要是读还是写。如果只读，考虑? extends T；如果只写，考虑? super T。第二步，问自己调用方是否真的需要传子类型。如果调用方永远只传精确类型，那用具体类型更简单清晰，不必强行上通配符。第三步，考虑API的长期演进。通配符会让签名更复杂，但换来更好的扩展性。如果是内部工具方法，简单优先；如果是公共API，灵活性优先。第四步，写测试验证。用不同层次的类型去调用，看看是否都能编译通过，行为是否符合预期。这里有一个我个人的经验：不要为了炫技而用通配符。我见过一些代码，明明调用方只传一种类型，方法签名却写得极其复杂，满屏的? extends和? super，维护成本很高。通配符是工具，不是目的，用在该用的地方就行。7. 进阶话题：自限定类型与递归泛型边界7.1 什么是自限定类型在阅读一些框架源码时，你可能会看到这样的签名：public class Builder<T extends Builder<T>> { public T withName(String name) { // ... return (T) this; } }T extends Builder<T>这种写法叫自限定类型（Self-Bounded Type），或者叫递归泛型边界。它的作用是让父类的方法返回子类的类型，从而支持流畅的链式调用。这个模式在构建器（Builder）模式中很常见。如果不这么写，父类的withName方法只能返回Builder，子类调用后就丢失了子类型信息，没法继续调用子类特有的方法。用了自限定类型之后，子类继承时把T指定为自己，父类方法就能返回子类类型了。7.2 递归边界的编译期检查自限定类型还有一个副作用：它能在编译期强制约束继承关系。比如：public abstract class Enum<E extends Enum<E>> { // ... }这是Java标准库中Enum类的签名。E extends Enum<E>意味着任何继承Enum的类，都必须把自己作为类型参数传进去。这种设计保证了枚举类型之间的比较是类型安全的。理解这个模式需要一点抽象思维，但核心逻辑不复杂：用类型参数来表示"子类自己"，从而让父类能够引用子类的类型。这是泛型边界的一个高级应用，日常业务代码用得不多，但读框架源码时经常遇到。7.3 通配符捕获与辅助方法有时候编译器无法直接推断通配符的具体类型，需要借助辅助方法来"捕获"类型。看这个例子：public static void swap(List<?> list, int i, int j) { // list.set(i, list.get(j)); // 编译错误 swapHelper(list, i, j); } private static <T> void swapHelper(List<T> list, int i, int j) { T temp = list.get(i); list.set(i, list.get(j)); list.set(j, temp); }List<?>既不能读成具体类型也不能写，直接操作会编译失败。但通过一个泛型辅助方法swapHelper，编译器可以捕获通配符为具体类型T，然后在辅助方法内部正常读写。这个技巧叫通配符捕获（Wildcard Capture），是处理无界通配符时的常用手段。这个模式在实际中不算常见，但当你需要对List<?>做写操作时，它是标准解法。记住这个套路，遇到类似问题时能省不少时间。8. 实操心得与避坑清单8.1 我踩过的几个典型坑坑一：以为List<Object>能接收一切。刚学泛型的时候，总觉得List<Object>是万能的，什么都能往里放。实际上List<Object>和List<String>之间没有任何赋值关系，List<String>不能赋给List<Object>。要接收各种类型的列表，得用List<?>或者List<? extends Object>。坑二：在extends通配符上调用add。这个前面说过了，但实际写代码时还是容易忘。特别是方法参数声明和实际传入类型不一致的时候，直觉上觉得"我传的就是List ，加个Integer怎么了"，但编译器只看声明。坑三：混淆? extends T和<T extends X>。这两个语法长得像，含义完全不同。? extends T是通配符边界，用在类型使用的位置；<T extends X>是类型参数声明，用在方法或类的定义上。前者是"某种未知的T子类型"，后者是"一个名为T的类型参数，它必须是X的子类型"。坑四：在返回值上用通配符。有些朋友会在方法返回值上写List<? extends Number>，这通常是个坏设计。因为调用方拿到这个返回值后，既不能读成具体类型（只能读成Number），也不能写，非常受限。返回值应该尽量用具体类型，把灵活性留给参数。8.2 通配符使用检查清单写泛型代码时，可以对照这个清单快速检查：方法参数是只读的吗？是的话考虑? extends T。方法参数是只写的吗？是的话考虑? super T。方法参数既读又写吗？是的话用具体类型，别用通配符。返回值上用了通配符吗？如果是，重新考虑设计。调用方需要传子类型吗？不需要的话，用具体类型更清晰。类型参数和通配符分清楚了吗？<T>是声明，<?>是使用。8.3 关于可读性的个人建议最后说一点关于代码可读性的体会。通配符虽然强大，但过度使用会让代码变得难以理解。我的原则是：如果一个方法签名需要超过两行才能写完，或者需要注释才能解释清楚，那就说明设计可能过于复杂了。在实际项目中，大部分业务代码用不到复杂的通配符。真正需要精细控制泛型边界的地方，通常是基础设施代码、工具类、框架扩展点。这些地方值得花时间把通配符用对，因为它们的复用率高，影响面大。而普通的业务逻辑，用具体类型反而更清晰、更好维护。另外，IDE的类型提示功能现在做得很好了，拿不准的时候把鼠标悬停在方法上，看看推断出来的类型是什么，往往能快速定位问题。我调试泛型问题时，经常用这招来确认编译器到底把?推断成了什么类型。如果这篇文章只能记住一句话，那就是：extends管读，super管写，读写都要就别用通配符。把这句话刻在脑子里，90%的泛型边界问题都能迎刃而解。剩下的10%，等你真正遇到的时候，再回来翻翻PECS原则和类型擦除那两节，基本就够用了。