1. 从一个编译报错说起为什么你的泛型代码总是不通过写了几年Java的人几乎都遇到过这样一种情况代码逻辑明明没问题IDE却给你标了一堆红编译器报的错还特别抽象比如incompatible types: List cannot be converted to List 。你盯着屏幕想Dog明明是Animal的子类凭什么List 就不能当List 用这不是天经地义的事吗这个问题背后牵扯出来的就是Java泛型系统里最容易被忽视、但在实际开发中又绕不开的两个核心概念协变Covariance与逆变Contravariance以及泛型的上下边界通配符——? extends T和? super T。很多朋友写业务代码时用泛型基本停留在ListString、MapString, Object这种层面一旦涉及到泛型之间的类型转换、方法参数设计、框架源码阅读就会卡住。比如你去看Java标准库里的Collections.copy方法签名或者Spring里的一些泛型工具类满屏的? extends和? super第一反应就是这写的什么玩意儿。这篇内容就是来解决这个问题的。我会从类型系统的底层逻辑出发把协变、逆变、不变这几个概念讲清楚然后把extends和super这两个通配符边界的使用场景、设计意图、常见坑点全部拆开揉碎。不管你是刚接触泛型的新手还是写了几年代码但对这块一直模棱两可的老手看完之后应该都能有一个清晰的心智模型。需要说明的是这篇文章不会只停留在语法层面告诉你这么写能编译通过而是会重点解释为什么Java要这么设计以及在实际项目里怎么用这套规则写出更安全、更灵活的代码。毕竟知道怎么用和知道为什么这么用是两回事。2. 类型系统的底层逻辑协变、逆变与不变到底是什么2.1 用生活场景理解三个核心概念先抛开Java代码用一个现实中的例子来建立直觉。假设我们有一个分类体系水果 → 苹果 → 红富士苹果。这是一个典型的继承链红富士是苹果的一种苹果是水果的一种。现在考虑一个容器的概念比如一个果篮。问题来了如果我把一篮苹果看作一篮水果这合理吗从直觉上说好像合理因为苹果本来就是水果。但从操作安全性上说就有问题了——如果一篮苹果可以被当作一篮水果来用那我往里面放一个香蕉行不行逻辑上它是一篮水果放香蕉应该可以但实际上这个篮子只能装苹果放香蕉就出事了。这就是类型系统里最核心的矛盾子类型关系能否安全地传递到容器类型上。三个术语分别对应三种不同的传递规则协变Covariance如果A是B的子类型那么ContainerA也是ContainerB的子类型。方向一致所以叫协变。数组在Java里就是协变的——Apple[]是Fruit[]的子类型。逆变Contravariance如果A是B的子类型那么ContainerB是ContainerA的子类型。方向反过来了所以叫逆变。不变Invariance不管A和B什么关系ContainerA和ContainerB之间没有任何子类型关系。Java的泛型默认就是不变的。用一句话总结协变是顺着继承方向走逆变是逆着继承方向走不变是各走各的互不相干。2.2 为什么Java泛型默认是不变的这个问题很关键理解了它后面所有的设计就都顺了。Java的泛型被设计成默认不变根本原因是类型安全。我们来看一段假设泛型是协变的代码注意这段代码在Java里编译不过只是用来演示逻辑// 假设Java允许这样写实际上不允许 ListApple apples new ArrayList(); ListFruit fruits apples; // 假设协变成立 fruits.add(new Banana()); // 编译通过因为Banana是Fruit Apple a apples.get(0); // 运行时炸了取出来的是Banana如果泛型是协变的那么ListApple就能赋给ListFruit然后你就可以往里面塞任何Fruit的子类。但实际底层数组还是Apple类型的塞进去一个Banana运行时就会抛ClassCastException或者ArrayStoreException。Java的设计者选择了在编译期就杜绝这种可能性所以泛型默认不变。ListApple和ListFruit就是两个完全不同的类型没有任何赋值兼容性。这个决定牺牲了一部分灵活性但换来了编译期的类型安全。注意数组是协变的这是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; }这个方法可以接受ListInteger、ListDouble、ListLong等任何Number子类型的列表。在方法内部你可以遍历、可以读取元素读出来的元素类型至少是Number所以调用doubleValue()是安全的。但你不能往里面写public static void addToList(List? extends Number list) { list.add(1); // 编译错误 list.add(1.0); // 编译错误 list.add(null); // 只有null可以 }为什么不能写因为编译器不知道这个?到底代表什么具体类型。它可能是ListInteger也可能是ListDouble。如果你能往里加Integer那万一实际是ListDouble呢类型就崩了。所以编译器干脆一刀切上边界通配符的集合只能读不能写除了null。从类型安全的角度看这个限制是必然的。读取的时候我们知道元素至少是Number所以能安全地当作Number用写入的时候我们不知道具体是哪个子类型所以任何写入都可能不安全。3.2 下边界super只能写读出来只能是Object再看? super Tpublic static void addNumbers(List? super Integer list) { list.add(1); list.add(2); list.add(3); }这个方法可以接受ListInteger、ListNumber、ListObject。在方法内部你可以往里面添加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不可以仅nullListNumber可以Number可以Number及其子类这张表建议存下来写代码拿不准的时候对照一下比翻文档快得多。4. 实战场景拆解什么时候该用extends什么时候该用super4.1 场景一设计通用的数据统计方法假设你在做一个数据分析模块需要对各种数值类型的集合求和。这时候方法参数应该用? extends Numberpublic 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(); } }调用方可以传ListInteger、ListDouble、ListBigDecimal都能正常工作。这里方法只读取数据不写入所以用extends是正确且安全的。如果你把参数写成ListNumber那调用方就必须把数据先转成ListNumber才能传进来非常别扭。这就是通配符带来的灵活性价值。4.2 场景二设计一个通用的数据收集器反过来如果你要设计一个往集合里批量添加数据的方法就应该用? super Tpublic class DataCollector { public static void collect(List? super Integer target, int count) { for (int i 0; i count; i) { target.add(i); } } }调用方可以传ListInteger、ListNumber、ListObject都能接收。方法内部只写入不读取所以用super是安全的。这个设计在实际中很有用。比如你有一个ListNumber想收集各种数值计算结果或者有一个ListObject想收集任意类型的数据都可以复用这个方法。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只写。这样设计之后调用非常灵活ListNumber dest new ArrayList(); ListInteger src Arrays.asList(1, 2, 3); copy(dest, src); // 完全合法如果不用通配符写成copy(ListT dest, ListT src)那ListNumber和ListInteger就没法一起用了必须类型完全一致。这就是通配符在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来产生比较结果。调用的时候ListInteger numbers Arrays.asList(3, 1, 4, 1, 5); ComparatorNumber numberComparator Comparator.comparingDouble(Number::doubleValue); Integer max max(numbers, numberComparator);ListInteger匹配? extends IntegerComparatorNumber匹配? super Integer类型推断正常工作。如果比较器写成ComparatorInteger当然也行但用ComparatorNumber更通用能复用于更多场景。5. 类型擦除带来的限制与坑点排查5.1 类型擦除泛型信息在运行时不存在要真正理解通配符的边界绕不开**类型擦除Type Erasure**这个概念。Java的泛型是编译期特性编译完成后所有的泛型信息都会被擦除。ListInteger和ListString在运行时都是List元素类型信息丢失了。这带来几个直接后果第一你不能用instanceof判断泛型类型ListInteger list new ArrayList(); if (list instanceof ListInteger) { } // 编译错误 if (list instanceof List?) { } // 这样可以第二你不能创建泛型数组ListInteger[] array new ListInteger[10]; // 编译错误第三你不能在静态上下文使用类的类型参数public class BoxT { private static T instance; // 编译错误 }理解类型擦除之后很多通配符的限制就变得理所当然了。编译器在编译期能拿到的类型信息有限所以它必须采取保守策略宁可拒绝一些理论上安全的操作也不放过任何可能不安全的操作。5.2 常见编译错误速查下面这张表整理了使用通配符时最常见的编译错误和原因错误信息典型代码根本原因解决方案incompatible typesListDog d new ArrayListAnimal();泛型不变用通配符或调整类型cannot be convertedListAnimal a dogList;泛型不变用? extends Animaladd cannot be appliedlist.add(x)其中list是List? extends T上边界不能写改用List? super Tincompatible 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这个声明在这个声明下写入操作一律禁止。后来改成了两个方案。方案一是把参数改成ListNumber牺牲了接受ListInteger的灵活性。方案二是拆成两个方法一个负责读一个负责写。最终选择了方案二因为调用方确实有传ListInteger的需求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(ListT list)这个签名信息量很大。T extends Comparable? super T的意思是T必须实现Comparable接口而且这个Comparable的比较对象类型是T或T的父类型。为什么要用? super T因为如果有一个类Student implements ComparablePerson那么Student对象可以和Person比较这是合理的。用? super T让这种设计成为可能。public static T void fill(List? super T list, T obj)fill方法是往列表里填充元素典型的消费者场景所以用? super T。这样ListObject也能被填充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也大量使用了通配符。比如StreamT filter(Predicate? super T predicate); R StreamR 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的链式操作非常灵活比如你可以用一个FunctionObject, String来处理StreamInteger。6.3 自己设计API时的通配符决策流程看了这么多源码可以总结出一个设计API时的决策流程第一步问自己这个方法主要是读还是写。如果只读考虑? extends T如果只写考虑? super T。第二步问自己调用方是否真的需要传子类型。如果调用方永远只传精确类型那用具体类型更简单清晰不必强行上通配符。第三步考虑API的长期演进。通配符会让签名更复杂但换来更好的扩展性。如果是内部工具方法简单优先如果是公共API灵活性优先。第四步写测试验证。用不同层次的类型去调用看看是否都能编译通过行为是否符合预期。这里有一个我个人的经验不要为了炫技而用通配符。我见过一些代码明明调用方只传一种类型方法签名却写得极其复杂满屏的? extends和? super维护成本很高。通配符是工具不是目的用在该用的地方就行。7. 进阶话题自限定类型与递归泛型边界7.1 什么是自限定类型在阅读一些框架源码时你可能会看到这样的签名public class BuilderT extends BuilderT { public T withName(String name) { // ... return (T) this; } }T extends BuilderT这种写法叫自限定类型Self-Bounded Type或者叫递归泛型边界。它的作用是让父类的方法返回子类的类型从而支持流畅的链式调用。这个模式在构建器Builder模式中很常见。如果不这么写父类的withName方法只能返回Builder子类调用后就丢失了子类型信息没法继续调用子类特有的方法。用了自限定类型之后子类继承时把T指定为自己父类方法就能返回子类类型了。7.2 递归边界的编译期检查自限定类型还有一个副作用它能在编译期强制约束继承关系。比如public abstract class EnumE extends EnumE { // ... }这是Java标准库中Enum类的签名。E extends EnumE意味着任何继承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(ListT 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 我踩过的几个典型坑坑一以为ListObject能接收一切。刚学泛型的时候总觉得ListObject是万能的什么都能往里放。实际上ListObject和ListString之间没有任何赋值关系ListString不能赋给ListObject。要接收各种类型的列表得用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原则和类型擦除那两节基本就够用了。 
长河君 · 2026/10/20 3:00:51 · 阅读 1.2k Java泛型协变逆变与通配符：PECS原则和上下边界详解
1. 从一个编译报错说起为什么你的泛型代码总是不通过写了几年Java的人几乎都遇到过这样一种情况代码逻辑明明没问题IDE却给你标了一堆红编译器报的错还特别抽象比如incompatible types: List cannot be converted to List 。你盯着屏幕想Dog明明是Animal的子类凭什么List 就不能当List 用这不是天经地义的事吗这个问题背后牵扯出来的就是Java泛型系统里最容易被忽视、但在实际开发中又绕不开的两个核心概念协变Covariance与逆变Contravariance以及泛型的上下边界通配符——? extends T和? super T。很多朋友写业务代码时用泛型基本停留在ListString、MapString, Object这种层面一旦涉及到泛型之间的类型转换、方法参数设计、框架源码阅读就会卡住。比如你去看Java标准库里的Collections.copy方法签名或者Spring里的一些泛型工具类满屏的? extends和? super第一反应就是这写的什么玩意儿。这篇内容就是来解决这个问题的。我会从类型系统的底层逻辑出发把协变、逆变、不变这几个概念讲清楚然后把extends和super这两个通配符边界的使用场景、设计意图、常见坑点全部拆开揉碎。不管你是刚接触泛型的新手还是写了几年代码但对这块一直模棱两可的老手看完之后应该都能有一个清晰的心智模型。需要说明的是这篇文章不会只停留在语法层面告诉你这么写能编译通过而是会重点解释为什么Java要这么设计以及在实际项目里怎么用这套规则写出更安全、更灵活的代码。毕竟知道怎么用和知道为什么这么用是两回事。2. 类型系统的底层逻辑协变、逆变与不变到底是什么2.1 用生活场景理解三个核心概念先抛开Java代码用一个现实中的例子来建立直觉。假设我们有一个分类体系水果 → 苹果 → 红富士苹果。这是一个典型的继承链红富士是苹果的一种苹果是水果的一种。现在考虑一个容器的概念比如一个果篮。问题来了如果我把一篮苹果看作一篮水果这合理吗从直觉上说好像合理因为苹果本来就是水果。但从操作安全性上说就有问题了——如果一篮苹果可以被当作一篮水果来用那我往里面放一个香蕉行不行逻辑上它是一篮水果放香蕉应该可以但实际上这个篮子只能装苹果放香蕉就出事了。这就是类型系统里最核心的矛盾子类型关系能否安全地传递到容器类型上。三个术语分别对应三种不同的传递规则协变Covariance如果A是B的子类型那么ContainerA也是ContainerB的子类型。方向一致所以叫协变。数组在Java里就是协变的——Apple[]是Fruit[]的子类型。逆变Contravariance如果A是B的子类型那么ContainerB是ContainerA的子类型。方向反过来了所以叫逆变。不变Invariance不管A和B什么关系ContainerA和ContainerB之间没有任何子类型关系。Java的泛型默认就是不变的。用一句话总结协变是顺着继承方向走逆变是逆着继承方向走不变是各走各的互不相干。2.2 为什么Java泛型默认是不变的这个问题很关键理解了它后面所有的设计就都顺了。Java的泛型被设计成默认不变根本原因是类型安全。我们来看一段假设泛型是协变的代码注意这段代码在Java里编译不过只是用来演示逻辑// 假设Java允许这样写实际上不允许 ListApple apples new ArrayList(); ListFruit fruits apples; // 假设协变成立 fruits.add(new Banana()); // 编译通过因为Banana是Fruit Apple a apples.get(0); // 运行时炸了取出来的是Banana如果泛型是协变的那么ListApple就能赋给ListFruit然后你就可以往里面塞任何Fruit的子类。但实际底层数组还是Apple类型的塞进去一个Banana运行时就会抛ClassCastException或者ArrayStoreException。Java的设计者选择了在编译期就杜绝这种可能性所以泛型默认不变。ListApple和ListFruit就是两个完全不同的类型没有任何赋值兼容性。这个决定牺牲了一部分灵活性但换来了编译期的类型安全。注意数组是协变的这是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; }这个方法可以接受ListInteger、ListDouble、ListLong等任何Number子类型的列表。在方法内部你可以遍历、可以读取元素读出来的元素类型至少是Number所以调用doubleValue()是安全的。但你不能往里面写public static void addToList(List? extends Number list) { list.add(1); // 编译错误 list.add(1.0); // 编译错误 list.add(null); // 只有null可以 }为什么不能写因为编译器不知道这个?到底代表什么具体类型。它可能是ListInteger也可能是ListDouble。如果你能往里加Integer那万一实际是ListDouble呢类型就崩了。所以编译器干脆一刀切上边界通配符的集合只能读不能写除了null。从类型安全的角度看这个限制是必然的。读取的时候我们知道元素至少是Number所以能安全地当作Number用写入的时候我们不知道具体是哪个子类型所以任何写入都可能不安全。3.2 下边界super只能写读出来只能是Object再看? super Tpublic static void addNumbers(List? super Integer list) { list.add(1); list.add(2); list.add(3); }这个方法可以接受ListInteger、ListNumber、ListObject。在方法内部你可以往里面添加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不可以仅nullListNumber可以Number可以Number及其子类这张表建议存下来写代码拿不准的时候对照一下比翻文档快得多。4. 实战场景拆解什么时候该用extends什么时候该用super4.1 场景一设计通用的数据统计方法假设你在做一个数据分析模块需要对各种数值类型的集合求和。这时候方法参数应该用? extends Numberpublic 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(); } }调用方可以传ListInteger、ListDouble、ListBigDecimal都能正常工作。这里方法只读取数据不写入所以用extends是正确且安全的。如果你把参数写成ListNumber那调用方就必须把数据先转成ListNumber才能传进来非常别扭。这就是通配符带来的灵活性价值。4.2 场景二设计一个通用的数据收集器反过来如果你要设计一个往集合里批量添加数据的方法就应该用? super Tpublic class DataCollector { public static void collect(List? super Integer target, int count) { for (int i 0; i count; i) { target.add(i); } } }调用方可以传ListInteger、ListNumber、ListObject都能接收。方法内部只写入不读取所以用super是安全的。这个设计在实际中很有用。比如你有一个ListNumber想收集各种数值计算结果或者有一个ListObject想收集任意类型的数据都可以复用这个方法。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只写。这样设计之后调用非常灵活ListNumber dest new ArrayList(); ListInteger src Arrays.asList(1, 2, 3); copy(dest, src); // 完全合法如果不用通配符写成copy(ListT dest, ListT src)那ListNumber和ListInteger就没法一起用了必须类型完全一致。这就是通配符在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来产生比较结果。调用的时候ListInteger numbers Arrays.asList(3, 1, 4, 1, 5); ComparatorNumber numberComparator Comparator.comparingDouble(Number::doubleValue); Integer max max(numbers, numberComparator);ListInteger匹配? extends IntegerComparatorNumber匹配? super Integer类型推断正常工作。如果比较器写成ComparatorInteger当然也行但用ComparatorNumber更通用能复用于更多场景。5. 类型擦除带来的限制与坑点排查5.1 类型擦除泛型信息在运行时不存在要真正理解通配符的边界绕不开**类型擦除Type Erasure**这个概念。Java的泛型是编译期特性编译完成后所有的泛型信息都会被擦除。ListInteger和ListString在运行时都是List元素类型信息丢失了。这带来几个直接后果第一你不能用instanceof判断泛型类型ListInteger list new ArrayList(); if (list instanceof ListInteger) { } // 编译错误 if (list instanceof List?) { } // 这样可以第二你不能创建泛型数组ListInteger[] array new ListInteger[10]; // 编译错误第三你不能在静态上下文使用类的类型参数public class BoxT { private static T instance; // 编译错误 }理解类型擦除之后很多通配符的限制就变得理所当然了。编译器在编译期能拿到的类型信息有限所以它必须采取保守策略宁可拒绝一些理论上安全的操作也不放过任何可能不安全的操作。5.2 常见编译错误速查下面这张表整理了使用通配符时最常见的编译错误和原因错误信息典型代码根本原因解决方案incompatible typesListDog d new ArrayListAnimal();泛型不变用通配符或调整类型cannot be convertedListAnimal a dogList;泛型不变用? extends Animaladd cannot be appliedlist.add(x)其中list是List? extends T上边界不能写改用List? super Tincompatible 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这个声明在这个声明下写入操作一律禁止。后来改成了两个方案。方案一是把参数改成ListNumber牺牲了接受ListInteger的灵活性。方案二是拆成两个方法一个负责读一个负责写。最终选择了方案二因为调用方确实有传ListInteger的需求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(ListT list)这个签名信息量很大。T extends Comparable? super T的意思是T必须实现Comparable接口而且这个Comparable的比较对象类型是T或T的父类型。为什么要用? super T因为如果有一个类Student implements ComparablePerson那么Student对象可以和Person比较这是合理的。用? super T让这种设计成为可能。public static T void fill(List? super T list, T obj)fill方法是往列表里填充元素典型的消费者场景所以用? super T。这样ListObject也能被填充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也大量使用了通配符。比如StreamT filter(Predicate? super T predicate); R StreamR 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的链式操作非常灵活比如你可以用一个FunctionObject, String来处理StreamInteger。6.3 自己设计API时的通配符决策流程看了这么多源码可以总结出一个设计API时的决策流程第一步问自己这个方法主要是读还是写。如果只读考虑? extends T如果只写考虑? super T。第二步问自己调用方是否真的需要传子类型。如果调用方永远只传精确类型那用具体类型更简单清晰不必强行上通配符。第三步考虑API的长期演进。通配符会让签名更复杂但换来更好的扩展性。如果是内部工具方法简单优先如果是公共API灵活性优先。第四步写测试验证。用不同层次的类型去调用看看是否都能编译通过行为是否符合预期。这里有一个我个人的经验不要为了炫技而用通配符。我见过一些代码明明调用方只传一种类型方法签名却写得极其复杂满屏的? extends和? super维护成本很高。通配符是工具不是目的用在该用的地方就行。7. 进阶话题自限定类型与递归泛型边界7.1 什么是自限定类型在阅读一些框架源码时你可能会看到这样的签名public class BuilderT extends BuilderT { public T withName(String name) { // ... return (T) this; } }T extends BuilderT这种写法叫自限定类型Self-Bounded Type或者叫递归泛型边界。它的作用是让父类的方法返回子类的类型从而支持流畅的链式调用。这个模式在构建器Builder模式中很常见。如果不这么写父类的withName方法只能返回Builder子类调用后就丢失了子类型信息没法继续调用子类特有的方法。用了自限定类型之后子类继承时把T指定为自己父类方法就能返回子类类型了。7.2 递归边界的编译期检查自限定类型还有一个副作用它能在编译期强制约束继承关系。比如public abstract class EnumE extends EnumE { // ... }这是Java标准库中Enum类的签名。E extends EnumE意味着任何继承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(ListT 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 我踩过的几个典型坑坑一以为ListObject能接收一切。刚学泛型的时候总觉得ListObject是万能的什么都能往里放。实际上ListObject和ListString之间没有任何赋值关系ListString不能赋给ListObject。要接收各种类型的列表得用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原则和类型擦除那两节基本就够用了。