Java泛型从入门到实战：泛型方法、类型擦除与通配符PECS完全解析

每次看到public <E> List<E> get()这种声明，留言区总有人问：这个<E>放在返回类型前面到底是干什么的？为什么T有时候写在类名后面，有时候又写在方法名前面？还有? extends和? super，背了八百遍PECS规则，一写代码还是报错？

这篇文章不打算装高深，就用我平时真实改代码的例子，把Java泛型从类到方法、从通配符到类型擦除一层层剥开。看完你至少能搞明白三件事：一类泛型该怎么设计，二方法是泛型怎么读懂和写出来，三为什么擦除之后还那么多坑。全程配合可运行的代码片段，你照着敲一遍比光看强十倍。

1. 泛型到底解决什么问题，先回到没有泛型的年代

很多讲泛型的文章喜欢直奔语法，结果新手看完只知道<T>是"随便一个类型"，根本不懂为什么要设计这些东西。所以我们先回到JDK 1.5之前，看看没有泛型的世界有多拧巴。

1.1 没有泛型的日子：强转、脏数据和运行期爆炸

在泛型出现之前，Java的集合类内部存的全是Object。这意味着你往List里塞一个字符串、塞一个整数、塞一个自定义对象，编译器全部放行，因为它们都能安全地向上转型成Object。看起来"灵活"，实际是灾难的温床。

List list = new ArrayList(); list.add("hello"); list.add(Integer.valueOf(42)); String first = (String) list.get(0); // 侥幸成功 String second = (String) list.get(1); // 运行期ClassCastException

这段代码编译期一切正常，只有运行到第5行才炸出异常。更麻烦的是，报错的位置往往离真正的"脏数据"写入点十万八千里。实际项目里，可能是一个工具类把Integer放进了本该只存字符串的list，另一个模块两百行之后去取，取完强转，然后整个接口就500了。排查成本极高。

那种"先存Object、取出来再强转"的模式，把类型安全的检查责任完全压到了程序员身上。人都会犯错，这种错误还特别隐蔽、特别难复现。大家之所以烦它，核心原因在这里。

1.2 泛型带来的三个价值：检查、省代码、抽象复用

泛型出来之后，上面的代码变成了这样：

List<String> list = new ArrayList<>(); list.add("hello"); // list.add(Integer.valueOf(42)); // 编译报错：类型不匹配 String first = list.get(0); // 不需要强转

看起来只是加了个<String>，但编译器替你把了一道关：写错类型当场报错，取出来直接就是目标类型。总结下来，泛型的价值集中在三个方面：

• 编译期类型检查：把原本运行期的ClassCastException提前到编译期，让错误在最早阶段暴露。这是泛型最核心的价值。
• 消除强制类型转换：代码不再到处是(String)这种强转，读起来干净，也不容易出现"转错类型"这种低级失误。
• 类型层面的代码复用和抽象：一个Box<T>可以装String、装Integer、装任意自定义类型，同一套逻辑对不同类型复用，而且这种复用仍然保留类型精度。

第三点尤其重要，它把"面向对象的多态"和"泛型的类型抽象"区分开来。继承也能复用代码，但继承要求类型之间有父子关系；泛型不要求，List<String>和List<Integer>之间没有继承关系，但List的代码逻辑可以服务两者。这是两种完全不同维度的抽象。

2. 泛型类：从最简单的Box到复杂继承关系

泛型类是比较容易理解的部分，因为它和普通类的写法差别不大，只是多了个类型参数列表。但万万不要觉得简单就跳过，类上的泛型和后面的泛型方法、类型擦除、通配符全都缠绕在一起。

2.1 基础写法：类型参数就是类里的"类型占位符"

如果你写一个最简单的盒子类，可以这样：

public class Box<T> { private T item; public void set(T item) { this.item = item; } public T get() { return item; } }

这里T就代表"将来使用Box时指定的那个类型"。使用的时候：

Box<String> stringBox = new Box<>(); stringBox.set("hello"); String s = stringBox.get(); Box<Integer> intBox = new Box<>(); intBox.set(42); Integer n = intBox.get();

编译器看到Box<String>之后，会认为这个实例内部的set方法参数必须是String，get方法的返回值也是String。如果往里面塞Integer，编译直接报错。

T这个名字没有任何魔法，它只是一个"类型变量"，你叫它T、E、K、V都行，行业内约定俗成而已：T代表Type、E代表Element、K和V代表Key和Value、R代表Result。

2.2 泛型类的继承：这里藏着最大的误区和隐藏规则

泛型类之间的继承，常见的写法有下面两种：

第一种，子类也保留类型参数：

public class StringProcessor<T> extends BaseProcessor<T> { // 子类和父类用的是同一个T }

这种场景适合"子类想沿用父类的类型处理逻辑，并且增加自己的一些行为"。例如BaseProcessor<T>实现公共的验证、序列化逻辑，子类StringProcessor<T>在此基础上扩展。

第二种，子类直接确定父类的类型参数：

public class StringProcessor extends BaseProcessor<String> { // 父类的T在继承时被确定成String }

这种写法意味着StringProcessor本身不再是一个泛型类，它就是一个普通类，专门处理String。用起来也更简单：new StringProcessor()就行。

但真正让很多人掉坑里的，是这个逻辑：Box<String>和Box<Object>之间没有任何继承关系。很多人觉得String是Object的子类，那Box<String>也应该是Box<Object>的子类吧？不是。

考虑下面这段代码，如果Box<String>是Box<Object>的子类会怎样：

Box<String> stringBox = new Box<>(); Box<Object> objectBox = stringBox; // 假设可以 objectBox.set(100); // 把一个Integer放进了"本该是String"的盒子里 String s = stringBox.get(); // 取出时强转失败

这就是泛型的"不变性"。数组是协变的，String[]可以赋给Object[]，所以才会出现著名的数组存储异常问题；泛型特意改成了不变，就是为了堵住这个漏洞——所有关于类型的正确性都在编译期锁定。

那如果确实想表达"某种T的父类"关系怎么办？答案是通配符，后面第五章专门讲。

2.3 类型参数的上界：给T加个约束条件

有时候你不想让类型参数完全"放飞"，希望它们必须继承某个父类或实现某个接口，这时候用extends关键字：

public class NumberBox<T extends Number> { private T number; public double doubleValue() { return number.doubleValue(); } }

有了这个上界，NumberBox<Integer>可以用，NumberBox<Double>可以用，NumberBox<String>直接编译失败。同时，在类内部，编译器还知道T至少是个Number，所以可以放心调用doubleValue()这些Number上的方法。如果没有上界，T会被擦除成Object，编译器压根不允许你调用Number的非Object方法。

这里记住一个关键：extends后面既可以跟类也可以跟接口，甚至可以用&连接多个限制，比如<T extends Comparable<T> & Serializable>，类必须排在第一个。这在后面的泛型方法里同样是规则。

3. 泛型方法：<T> T和T到底差在哪

现在到标题里最核心的部分了。很多朋友就是卡在这里：类名上已经有了<T>，方法前面怎么还有个<T>？这个<T>和类名上的<T>是不是同一个？不搞清楚这个，后面public <E> List<E> get()永远是"看着眼熟、写起来手生"。

3.1 方法声明里没写<T>时，T来自类上

先看没有在方法前声明类型参数的场景：

public class Wrapper<T> { private T value; public T getValue() { return value; } public void setValue(T value) { this.value = value; } }

这里的getValue()返回类型是T，但这个T不是方法自己发明的，它来自类名上的Wrapper<T>。也就是说，当你在类上声明了类型参数T之后，类里的实例方法天然就能使用这个T，不需要再在方法前面重复声明一遍。

这就是很多人混淆的起点：看到public T getValue()，以为T是"凭空出现"的关键字。其实它只是类的一个成员，作用范围是整个类体，包括实例字段、实例方法、内部类。但注意，静态方法不能用类上的T，原因后面说。

3.2 方法前写<T>时，T属于方法自己

再来看另一种：

public class Util { public static <T> T getMiddle(T[] array) { if (array == null || array.length == 0) { return null; } return array[array.length / 2]; } }

注意public static和<T>之间的顺序：先修饰符，再声明类型参数，再写返回类型。这个<T>声明了一个方法级别的新类型变量，它的作用域仅限于当前方法。方法参数里的T、返回值里的T，都指向这个新声明的方法级T，与任何类上的类型参数无关，即使这个类恰好也叫Util<T>。

这是理解标题里<T> T的关键：第一个<T>是"声明"，第二个T是"返回类型中使用这个声明"。

3.3 逐字拆解public <E> List<E> get()

现在拿到经典这句：

public <E> List<E> get()

一个词一个词拆：

• public：访问修饰符。
• <E>：声明这是一个泛型方法，方法内部使用一个叫E的类型变量。
• List<E>：返回类型。返回的不是裸List或List<Object>，而是"元素类型为E的List"。E到底是什么，由编译时的上下文推断。
• get()：方法名，无参数。

所以这个方法的含义是：该方法在执行过程中会产生某种类型E的元素，最终把这些元素放进一个List<E>返回，调用方不需要强转，直接拿到目标类型。

举个例子，假设我要从一个Set里拷贝元素到新的List：

public <E> List<E> copyFromSet(Set<E> set) { List<E> list = new ArrayList<>(); if (set != null) { list.addAll(set); } return list; }

调用的时候，编译器会根据Set<String>自动推断出E是String，返回的List<String>直接赋值：

Set<String> names = new HashSet<>(); names.add("张三"); names.add("李四"); List<String> nameList = copyFromSet(names); // 类型推断，无需强转

如果方法没有写<E>，而是直接写public List get()，则返回的是裸List，调用方就得自己强转，一旦里面混入不同类型元素，运行期可能炸ClassCastException。这就是为什么写工具类时，泛型方法比裸类型返回更可靠。

3.4 类型推断和显式类型实参

编译器怎么知道E是什么？其实是通过方法参数推断出来的：实参names是Set<String>，而形参是Set<E>，于是E = String，返回值List<E>自然就成了List<String>。这种机制叫"目标类型推断"。

但如果你希望强制指定某类型，可以这样显式写：

List<String> result = Util.<String>getMiddle(new String[]{"a","b","c"});

不过Java 8之后推荐上下文推断，大多数场景根本不需要显式写类型实参，写多了反而啰嗦。

还有一种情况是返回值和方法参数无法建立约束关系。比如：

public <T> T build(Class<T> clazz) throws Exception { return clazz.getDeclaredConstructor().newInstance(); }

调用时：

User user = build(User.class);

这里T是通过Class<T>这个参数推断出来的。反射场景特别常见，很多框架的底层工厂方法就是这么写的。

3.5 静态方法为什么必须自带泛型声明

前面埋了个伏笔：静态方法不能用类上的T。原因是静态方法不依赖类的实例，它在类加载阶段就存在，而类型参数T是跟着实例走的——Wrapper<String>和Wrapper<Integer>是不同的类型。静态方法不属于任何实例，自然访问不到实例级别的T。

所以如果想在静态方法里用泛型，唯一的办法就是自己声明一个方法级的类型变量：

public class Factory { public static <T> T create(Class<T> clazz) throws Exception { return clazz.getDeclaredConstructor().newInstance(); } }

这也是java.util.Collections里大量工具方法static <T> void sort(...)、static <T> List<T> unmodifiableList(...)能在静态上下文中使用泛型的原因。

3.6 泛型方法的边界约束和重载陷阱

泛型方法同样可以加边界：

public <T extends Comparable<T>> T max(T[] array) { if (array == null || array.length == 0) { return null; } T max = array[0]; for (int i = 1; i < array.length; i++) { if (array[i].compareTo(max) > 0) { max = array[i]; } } return max; }

这个约束告诉编译器：T必须是可比较的，这样就能放心调用compareTo。如果不加边界，T被擦除成Object，Object上没有compareTo方法，编译器直接拒绝。

泛型方法还有一个很隐蔽的坑——重载冲突。想写两个方法：

public void print(List<String> list) {} public void print(List<Integer> list) {}

编译直接报错"类型擦除后冲突"。因为List<String>和List<Integer>在擦除后都是原生List，两个方法签名相同。这个和泛型方法本身无关，是泛型擦除导致的重载误伤，第四章会展开说。想区分不同类型，你只能换方法名。

4. 类型擦除：泛型为什么只是编译期的"幻觉"

如果只停留在"会用泛型"的层面，类型擦除可以不深究。但当你阅读框架源码、写底层工具或者调试泛型各种诡异编译错误时，不理解擦除原理基本等于瞎子摸象。

4.1 编译之后，类型参数去哪了

Java的泛型只在编译阶段生效。编译器用类型参数完成类型检查后，会执行一个"擦除"操作：把代码中所有的类型参数替换成它的上界（如果没有上界就是Object），然后在我们需要强转的地方自动插入类型转换。

来看一个例子：

public class Box<T extends Number> { public T get() { /* ... */ } public void set(T item) { /* ... */ } }

编译成字节码后，T会被替换成Number。方法内部看起来就像：

public class Box { public Number get() { ... } public void set(Number item) { ... } }

而使用端：

Box<Integer> box = new Box<>(); Integer n = box.get();

编译器发现get()实际返回Number，而目标是Integer，就自动插入了(Integer)强转。所以从字节码层面看，强转还是存在的，只不过编译器帮我们放好了位置，而且保证不会转错。

4.2 用反射验证擦除的存在

写一段代码就能直观感受到擦除：

public class ReflectionTest { public static void main(String[] args) throws Exception { List<String> stringList = new ArrayList<>(); List<Integer> integerList = new ArrayList<>(); System.out.println(stringList.getClass() == integerList.getClass()); // 输出 true，二者在运行时都是 ArrayList.class } }

List<String>和List<Integer>在Java虚拟机里就是同一个类ArrayList。你没法在运行时判断一个List是String的还是Integer的，擦除已经把类型参数信息从字节码里抹掉了。

很多人刚知道这一点时会很不爽："那泛型有什么用？"其实结论恰好相反：正因为擦除，Java的泛型才能保持向后兼容，老的JDK代码、老的第三方库、老的内存布局都不需要改变。这也是Java选择擦除方案的原因，和C#那种在运行时保留类型参数真实信息的"reified泛型"是两种不同的设计哲学。

4.3 擦除带来的六个具体限制

擦除绝不是无代价的，它带来一堆硬性的语法限制，每一条背后都是实际崩溃现场总结出来的：

• 不能new T()：因为擦除后T是Object，new Object()和你想创建的T类型完全对不上。遇到"想创建T实例"的需求，通常改成传入Supplier<T>或者Class<T>反射创建。
• 不能用instanceof T：擦除后T变成Object，obj instanceof T会变成obj instanceof Object，这个判断永远为true，毫无意义。
• 不能直接new T[]：泛型数组创建在运行期会因为类型信息丢失而无法保证数组存储的类型安全。替代方案是用ArrayList<T>，或者用Array.newInstance(Class<T>, int)反射创建。
• 静态字段不能使用类级类型参数：刚才说过，静态成员属于类，而类型参数属于实例，天然冲突。
• 类型参数不能用于异常捕获：你不能写catch (T e)，因为异常系统的运行期匹配需要精确类型，而泛型被擦除了。
• 重载陷阱：void m(List<String>)和void m(List<Integer>)擦除后签名相同，无法并存。

擦除本身并不复杂，但它解释了Java泛型里80%的"为什么这么设计"。了解这些限制以后，再看框架源码里的Class<T>参数、Supplier<T>参数，就会明白那都是为了绕过擦除。

5. 通配符：让泛型在继承和复用之间找到平衡

第二章说过，Box<String>和Box<Object>没有继承关系，这是泛型的不变性。但这个"极度的安全"也带来一个副作用：代码灵活度降低。如果有一个方法只需要读取Box里的元素，不管它是Box<String>还是Box<Integer>，总不能写两个重载吧？这时候就轮到通配符登场。

5.1<?>无界通配符：表示"某种类型"

最简单的通配符是?，代表"某种未知的类型"。注意，是未知，不是"任何类型都行，随便往里塞"。

public static void printList(List<?> list) { for (Object obj : list) { System.out.println(obj); } }

这个方法可以接收List<String>、List<Integer>、List<Foo>。因为元素类型未知，循环变量统一按Object处理。

但如果想往List<?>里添加元素呢？

List<?> list = new ArrayList<String>(); // list.add("hello"); // 编译错误：无法确定add的参数类型 list.add(null); // 唯一允许的“值”，因为null可以赋给任何类型

原因很直接：list的实际类型可能是List<String>，也可能是List<Integer>，编译器只知道"某种类型"，但无法确定哪种，干脆禁止任何非null的写入。所以List<?>适合"只读"场景。

这里有一个常见的操作误区：List<?>和List<Object>不一样。List<Object>能接收任何Object子类，但它本身只能赋给List<Object>；List<?>是个"更宽泛"的类型，可以接收所有List<T>的引用，但在读取时你只知道元素是Object。

5.2? extends T上界通配符：安全读取，禁止写入

如果希望方法接收"元素类型是T的某个子类的List"，用? extends T：

public static double sum(Collection<? extends Number> numbers) { double total = 0; for (Number n : numbers) { total += n.doubleValue(); } return total; }

这个方法能接收List<Integer>、List<Double>、Set<BigDecimal>，因为它们都是"Number的某种子类"。读取的时候，可以保证元素至少是Number，所以直接按Number遍历。

但是，还是不能写入。想想为什么：入参可能是List<Integer>，如果你往里面add(new Double(1.5))，对于真正的List<Integer>来说就是写入了Double，违类型安全。编译器不知道具体子类型，所以一律禁止。

5.3? super T下界通配符：可以写入，读取却受限

反过来，? super T表示"某种T的父类型"。典型场景是往集合里添加T及其子类对象：

public static void addNumbers(List<? super Integer> list) { list.add(Integer.valueOf(1)); list.add(2); // list.add(Double.valueOf(1.5)); // 编译错误，Double不是Integer }

这里入参可以是List<Integer>、List<Number>、List<Object>，总之是Integer的某个父类类型。因为目标集合的元素类型是Integer的父类，往里面放Integer肯定安全——Integer一定是这个父类的子类型。

但读取就尴尬了：由于集合元素类型可能是Number、Object或Integer，你只知道它是Object，无法确定更具体的类型。所以? super在处理"写入"时好用，读取时通常只能按Object取值。

5.4 PECS规则：Producer Extends, Consumer Super

这章是整篇文章里最值得背的一句话。PECS规则是Effective Java作者Joshua Bloch提出的，它精确回答了"什么时候用extends、什么时候用super"：

• 如果你只需要读取集合里的元素来生产数据，用? extends T（Producer）。
• 如果你只需要写入元素到集合，让集合消费这些数据，用? super T（Consumer）。
• 如果既读又写，那就老老实实直接用T，别用通配符。

看一个最经典的Collections.copy思路：

public static <T> void copy(List<? super T> dest, List<? extends T> src) { for (int i = 0; i < src.size(); i++) { dest.set(i, src.get(i)); } }

src是生产者，读元素出来，所以用? extends T；dest是消费者，收元素进去，所以用? super T。这种声明既灵活又安全。

其实不用死记口诀，每次写完通配符后问自己一个问题：这个集合里的元素会"被读出来"还是"被塞进去"？读出来用extends，塞进去用super，两边都有就直接T。

5.5 通配符和类型参数的选择：灵活度与复杂度的博弈

既然通配符这么方便，是不是能看见?就往上套？不是。实际编码中，我喜欢按以下经验判断：

优先使用类型参数<T>，当你有以下需求：

• 返回值里有T，且调用方想直接拿到具体类型。
• 多个参数之间有关联，void put(K key, V value)中两个参数需要"成对"的同一类型。
• 方法内部需要把参数传给另一个泛型方法，类型参数比通配符更容易传播。

优先使用通配符?，当满足：

• 方法内部只读，不写。
• 方法的逻辑和具体类型无关，比如打印所有元素、统计数量。
• 你想表达"这个参数可以是家族中的任意一员"，而不是"某个固定但尚未确定的类型"。

举个反例，如果你写：

public <T> T getFirst(List<T> list) { return list.get(0); }

其实完全可以用?配合类型推断来减少声明：

public static Object getFirst(List<?> list) { return list.get(0); }

但这样返回的就是Object，调用方拿不到精确类型。所以如果你希望返回String、Integer这些具体类型，就必须用泛型方法而不是通配符。通常我会让"返回类型需要精确"的方法走<T>，只读辅助工具走?。

6. 实战中的高频坑：泛型编译错误速查与排查思路

前面理论讲了不少，真正写代码时还是容易被编译器和各种怪问题教训。这章整理一下我个人在项目中踩过、也被读者问过最多的几个泛型问题，附排查思路和解决方案。

6.1 常见错误速查表

6.2 踩坑实录：调用泛型方法时类型参数推断失败

有一次我在项目里写了一个批量转换方法：

public static <T> List<T> convert(List<?> source, Function<Object, T> mapper) { return source.stream().map(mapper).collect(Collectors.toList()); }

调用的时候写了这样一段：

List<String> names = convert(rawList, obj -> obj.toString());

编译器竟然报类型推断失败。原因是rawList是List<?>，传入后它与mapper的Object类型推断互相纠缠，导致T推不出来。我最后把方法改成：

public static <T> List<T> convert(List<?> source, Function<Object, T> mapper)

其实签名没问题，问题出在调用方的rawList用了裸类型。改成：

List<?> rawList = ... List<String> names = convert(rawList, (Function<Object, String>) String::valueOf);

显式指定Function<Object, String>之后，T就确定为String，就过了。这种"推断失败"在Java 8前后差异很大，新版编译器普遍更聪明，但遇到聚在一起的多层泛型时，显式加个类型实参或者类型转换，往往比硬看编译器脸色快。

6.3 踩坑实录：通配符两端误用导致只读变只写

有一次我在封装一个缓存查询工具，想支持"从缓存取出某种类型的列表"，写了如下代码：

public List<? extends Object> getCacheList(String key) { return (List<? extends Object>) redisTemplate.opsForValue().get(key); }

这个返回声明看着没问题，但调用方想把它直接赋给List<String>就报错。因为List<? extends Object>虽然能读，但编译器不肯把它当List<String>用。后来我改成泛型方法：

public <T> List<T> getCacheList(String key, Class<T> clazz) { Object val = redisTemplate.opsForValue().get(key); List<?> raw = (List<?>) val; List<T> result = new ArrayList<>(); for (Object item : raw) { result.add(clazz.cast(item)); } return result; }

通过clazz.cast(item)逐一强转，编译器能确认返回的是List<T>，调用方直接拿List<String>接收，清晰多了。这个小例子也说明：当通配符阻塞了返回类型的精确传递，别硬扛，换回泛型方法通常是最短路径。

6.4 踩坑实录：泛型类和泛型方法重名导致的"自我覆盖"

还有一种比较刁钻的情况：类上有类型参数，方法里又声明了一个同名的类型参数，编译器优先使用方法内的类型变量。看代码：

public class Example<T> { public <T> T shadow(T input) { System.out.println("T inside method"); return input; } }

方法内的<T>把类上的<T>遮蔽了，方法实现里用的完全是另一个类型变量。这种写法不报错，但可读性极差，容易误导人。我的建议是：类级类型参数和方法级类型参数遵循不同命名习惯，比如类上用T，方法上用E、R等，能让代码意图清晰很多。

7. 一个完整的泛型类+泛型方法+通配符的练习案例

如果你已经把前面内容读到这里，不如直接看一个综合案例，把零散的知识点串起来。我设计一个极简的"通用的缓存仓库"，它同时用到泛型类、泛型方法、类型擦除的绕行方案和通配符边界。

public class GenericRepository<T> { private final Map<String, T> store = new HashMap<>(); // 泛型方法：带独立类型变量，把外部DTO转成T后存入 public <D> void saveFromDto(String id, D dto, Function<D, T> converter) { T entity = converter.apply(dto); store.put(id, entity); } // 普通方法：使用类级类型参数T public T get(String id) { return store.get(id); } // 泛型边界：只处理T的某个父类映射 public <R super T> void saveAsParent(String id, R value) { // 如果是JDK 21（Preview），允许super通配符用于类型参数中 // 稳定版本中不推荐，一般改用 T或? super T做参数 } // 通配符读取：合并多个仓库中的所有数据 public void mergeFrom(GenericRepository<? extends T> source) { // 由于是 ? extends T，可以安全读取 // 但不能直接 put 回 source，下面只能加到本仓库 Map<String, ? extends T> sourceData = source.store; for (Map.Entry<String, ? extends T> entry : sourceData.entrySet()) { this.store.put(entry.getKey(), entry.getValue()); } } }

不过<R super T>那个方法在Java标准版本中并不推荐，只是我看了JDK 21的预览特性才想起来提一嘴。大多数情况下，我们要在方法里同时写T和T的父类时，直接使用? super T作为参数类型更现实。我改一下案例，避免读者踩到不成熟语法的坑：

public class GenericRepository<T> { private final Map<String, T> store = new HashMap<>(); public <D> void saveFromDto(String id, D dto, Function<D, T> converter) { T entity = converter.apply(dto); store.put(id, entity); } public T get(String id) { return store.get(id); } // 下界通配符：允许把"T或T的子类"放入容器 public void addAll(List<? extends T> items) { for (T item : items) { store.put(UUID.randomUUID().toString(), item); } } // 消费者通配符：允许把本仓库内容输出到某个"T的父类型集合" public void exportTo(List<? super T> target) { target.addAll(store.values()); } }

这里addAll接收? extends T，因为我们需要从中读取元素，是生产者；exportTo接收? super T，因为我们需要往它写入本仓库的T，是消费者。一个类里的两种通配符各司其职，恰好呼应了PECS规则。

代入一个实际场景：

GenericRepository<Number> numberRepo = new GenericRepository<>(); List<Integer> ints = List.of(1, 2, 3); numberRepo.addAll(ints); // ? extends Number List<Object> bucket = new ArrayList<>(); numberRepo.exportTo(bucket); // ? super Number

这个例子中，GenericRepository<Number>既能合并List<Integer>，又能把Number导出到List<Object>。如果不用通配符，这两个调用直接编译不过。这也是通配符在实际封装里真正的价值：在类型安全前提下，把不变性破开一个口子，让类型家族可以互相协作。

8. 关于泛型，我最后的几点实战心得

写了这么多年Java，每次用泛型都会有些新的体会。把我的个人经验放在这里，大家可以少走弯路。

第一，泛型不是"银弹"，不要为了炫技而滥用。我看到过有人把简单的工具方法强行套三层泛型，调用方解类型都要解半天。泛型的核心价值是类型安全和抽象复用，如果业务里所有类型都是明确的、不会变化的，那就直接写具体类，别硬套。泛型最适合应用在通用库、框架、公共工具类这些"不知道未来会被什么类型调用"的地方。

第二，读框架源码时，先看懂类型参数声明的位置，再关注方法内部逻辑。因为类型参数声明的位置决定了变量的作用域和作用。每看到public <T> List<T> xxx(...)这种签名，默念一遍"'<'之后的是声明，返回类型里的是使用"，很多困惑就自动消失了。

第三，遇到编译错误先怀疑擦除和通配符方向，再去怀疑业务逻辑。七个常见的错误我在第六章列了表，其中一大半都和"泛型不变性""擦除""通配符读写限制"有关。把这些原理背熟，编译错误处理速度会直线上升。

第四，List裸类型能不用就不用。即使你的代码在旧系统里暂时不得不使用裸集合，也尽量在边界处转换成带类型的集合再往上层传。我在实际项目里清理过不少裸List引发的运行期ClassCastException，每次都深刻体会到：类型安全这东西，编译期不堵住，运行期就一定找上门。

实话讲，泛型这个主题看起来语法点很多，但核心线索非常清晰：泛型类解决的是"类级别的类型抽象"，泛型方法解决的是"方法级别的类型抽象"，类型擦除解释了这些抽象在JVM里如何落地，通配符则解决了泛型不变性带来的灵活性不足。把这四条线理清楚，任何泛型代码拿到手都不会再发怵。以后再看到public <E> List<E> get()，你应该能条件反射地读出来：声明一个方法级类型变量E，返回值是一个元素类型为E的List，具体E由调用方推断决定。