不能往 list 中 add 非 null 元素，因为 ? 表示未知但具体的实际类型，编译器无法验证元素类型安全性；null 除外，因其是所有引用类型的合法值。
向 List> 这类无界通配符列表中调用 add() 方法时，编译器会直接报错，比如：error: no suitable method found for add(String)。这不是 JVM 运行时问题，而是 Java 泛型的**编译期类型检查机制**在起作用——关键在于理解“无界通配符”语义和“捕获转换”（capture conversion）的真实角色。
为什么不能往 List> 里 add 任何非 null 元素？
声明 List> list = new ArrayList<string>();</string> 并不表示“能装任意类型”，而是表示“这个列表的元素类型是某个**未知但具体**的类型（比如 String、Integer 或自定义类），只是当前上下文不知道它到底是哪一个”。编译器必须保证类型安全：既然不知道实际类型，就无法验证你传入的 "hello" 是否符合那个隐藏的具体类型。
所以除 null 外，所有 add() 调用都被禁止——因为 null 是所有引用类型的合法值，不会破坏类型契约。
捕获转换不是“绕过限制”的技巧，而是类型推导的中间步骤
捕获转换（JLS §5.1.10）是编译器内部对通配符类型进行**临时具名化**的过程，仅用于方法重载解析、类型兼容性判断等场景，**不改变变量声明的约束**。
- 例如，调用
Collections.sort(list)时，编译器会对List extends Comparable>>做捕获，生成类似List（其中 #1 是一个新鲜类型变量），再检查#1是否满足Comparable—— 这是为方法调用服务的，不是给用户开放的“类型别名”。 - 你**无法显式写出捕获变量**（如
List），也不能用它声明变量或转型。 - 试图通过反射、强制转型或泛型方法“欺骗”编译器往
List>加元素，只会掩盖问题，导致运行时ClassCastException（比如把Integer加进本应只存String的列表）。
真正实用的替代方案
遇到想“通用地操作列表但又需添加元素”的需求，应根据实际意图选择更精确的泛型表达：
-
如果你确定所有元素都是同一具体类型：直接用
List<string></string>、List<number></number>等，而非List>。 -
如果你需要接收多种子类型并读取（只读场景）：用上界通配符，如
List extends Number>，可安全获取Number及其子类实例，但依然不能add（除非是null）。 -
如果你需要写入多种子类型（生产者场景）：用下界通配符，如
List super Integer>，此时可以add(new Integer(42))、add(new Long(1L))（只要它们是Integer的父类），但读取时只能当作Object。 -
如果必须动态混合类型且类型安全不可妥协：考虑用
List<object></object>，或封装成支持多态的容器（如sealed class Element+ 模式匹配），而不是依赖通配符妥协类型系统。
快速验证与调试建议
当遇到泛型编译错误，别急着查“怎么绕过”，先做三件事：
- 用
javac -Xlint:unchecked编译，看是否暴露了隐式擦除警告； - 把通配符替换成具体类型（如
String），确认逻辑本身是否成立； - 用 IDE（IntelliJ/Eclipse）把鼠标悬停在泛型变量上，查看它推断出的“实际类型参数”——往往比想象中更严格。
捕获转换是编译器后台的“隐形胶水”，理解它有助于读懂错误信息，但解决问题靠的是选对泛型边界，不是解构魔术。
