通配符捕获是Java编译器自动启用的类型推断机制，用于临时为? extends T或? super T引入唯一未知类型变量（如capture#1），在方法调用等场景中恢复局部类型一致性，使原本因泛型不变性被拒的操作合法，但不改变运行时擦除本质。
Java 泛型的通配符捕获（Wildcard Capture）不是一种显式语法，而是一种编译器在类型推断过程中自动启用的机制，用于解决“看似合理却报错”的泛型赋值问题——尤其是涉及 ? extends T 或 ? super T 的变量间赋值、方法调用或类型传递时，编译器因无法确认具体类型参数而拒绝操作。它的核心作用是：让编译器临时为通配符引入一个**未知但唯一**的类型变量（如 capture#1 of ?），从而在局部范围内恢复类型一致性，使原本被拒的操作变得合法。
为什么直接赋值会失败？——通配符的不可变性本质
Java 中的 List<? extends Number> 并不表示“某个具体的子类型列表”，而是“某个未知子类型的列表”。编译器只知道它装的是 Number 或其子类，但不知道到底是 Integer、Double 还是别的。因此：
-
List<? extends Number> src = new ArrayList<Integer>();✅ 合法（上界安全） -
List<Number> dst = src;❌ 报错：不能将List<capture#1 of ? extends Number>赋给List<Number> - 原因：虽然
Integer是Number子类，但List<Integer>和List<Number>并不存在继承关系；而src的真实类型可能是List<BigDecimal>，强制转成List<Number>会破坏类型安全。
通配符捕获如何悄悄“救场”？——发生在方法调用时
捕获机制本身不写在代码里，但它会在你调用接受通配符参数的方法时自动触发。例如：
public static <T> void copy(List<? extends T> src, List<T> dst) {
for (T item : src) { // ✅ 编译器捕获了 ? 为某个具体 T-subtype，允许读取为 T
dst.add(item);
}
}
当你写：copy(new ArrayList<Integer>(), new ArrayList<Number>());，编译器会：
立即学习“Java免费学习笔记（深入）”；
- 把第一个参数
List<? extends Number>中的?捕获为一个隐式类型变量（比如 capture#1），并确认它满足capture#1 <: Number - 于是循环中
item的类型被推为capture#1，而capture#1是T（即Number）的子类型，可安全赋给T - 这样既没破坏类型安全，又允许跨类型列表读取
手动模拟捕获：用泛型方法封装“危险操作”
当需要对通配符集合做写入、转换或比较等操作时，最可靠的方式是定义一个私有泛型辅助方法，把通配符“提升”为具名类型参数：
// 错误示例（直接操作通配符列表）
void badAdd(List<? super Integer> list) {
list.add(1); // ✅ 允许（下界支持写入）
list.add(2L); // ❌ 报错：Long 不是 ? super Integer 的保证成员
}
// 正确做法：用捕获式泛型方法
<T> void safeAdd(List<T> list, T item) {
list.add(item); // ✅ 类型完全匹配
}
// 调用时：
List<? super Integer> list = new ArrayList<Number>();
safeAdd(list, 42); // 编译器捕获 ? super Integer 为实际类型（如 Number），再传给 T
关键点：
- 泛型方法的类型参数
T在调用时由实参推导，相当于把模糊的通配符“落地”为一个确定（但仍是泛型）的类型 - 避免在方法签名中暴露通配符给调用方，内部用
<T>消除不确定性 - 适用于集合拷贝、元素提取、条件过滤等常见场景
什么时候捕获不起作用？——边界之外的操作仍受限
捕获只能缓解“读取上界”和“写入下界”的部分限制，但不会改变泛型不变性（invariance）的根本规则：
-
List<? extends Number>仍不能往里add(...)（除了null），因为编译器不知道具体子类型 -
List<? super Integer>仍不能安全地get(0)为Integer（只能得到Object），因为下界不保证返回类型 - 捕获不等于类型擦除逆转——运行时依然没有泛型信息，所有检查都在编译期完成
真正需要灵活读写时，应优先考虑设计更合理的泛型接口（如使用 PECS 原则），而不是依赖捕获绕过限制。
