java泛型通配符的限制源于pecs原则：? extends t仅可读不可写（除null），? super t仅可写不可精确读，需依操作意图选用合适通配符类型，而非“绕过”限制。

这个问题其实不是“捕获技术”能解决的，而是对 Java 泛型通配符语义的误解所致。所谓“无法向带通配符集合中添加除 null 外任何元素”，是 ? extends T 类型的合法限制，不是缺陷，更不需要“绕过”或“捕获”。关键在于选对通配符类型，匹配操作意图。

先分清：你到底想读，还是想写？

Java 泛型通配符设计严格遵循 PECS 原则（Producer-Extends, Consumer-Super）：

• ? extends T：只适合做“生产者”——安全读取 T 或其子类实例，但禁止写入（除 null），因为实际类型可能是任意子类，编译器无法校验你 add 的对象是否兼容
• ? super T：只适合做“消费者”——允许写入 T 及其子类对象，但读取时只能当作 Object（类型太宽泛，无法保证具体子类型）

为什么 List extends Number> 不能 add(1.0)？

假设你声明：List extends Number> list = new ArrayList<integer>();</integer>

此时 list 实际引用的是 ArrayList<integer></integer>，但编译器只知道它“是某个 Number 的子类型列表”，可能是 ArrayList<integer></integer>，也可能是 ArrayList<double></double> 或 ArrayList<biginteger></biginteger>。如果你调用 list.add(1.0)（即 Double），就会破坏 ArrayList<integer></integer> 的类型安全——这正是编译器阻止它的根本原因。

所以这不是“窘境”，而是类型系统在保护你。

实战解法：按场景切换通配符类型

不要强行往 ? extends T 里塞东西。正确做法是：

• 如果方法职责是处理已有数据（遍历、计算、转换）→ 用 List extends Number>，只读不写
• 如果方法职责是收集/填充数据（如归并、聚合、批量插入）→ 改用 List super Number>，可安全 add(Number 及其子类)
• 如果既要读又要写 → 放弃通配符，直接用具体类型，如 List<number></number> 或泛型方法 <t> void process(List<t> list)</t></t>

一个典型对比示例

下面两个方法各司其职，互不干扰：

// ✅ 安全读取：接受所有 Number 子类列表
void printNumbers(List extends Number> src) {
    for (Number n : src) System.out.println(n);
}
// ❌ 编译失败：list.add(3.14); // 不允许

// ✅ 安全写入：可接收 List<number>、List<object> 等
void fillWithZeros(List super Number> dest, int count) {
    for (int i = 0; i 
</object></number>