List<?>禁止添加非null元素是编译期类型安全机制，因其表示“未知但具体”的类型，编译器无法验证添加元素的兼容性；null被允许因它是所有引用类型的合法值；读取返回Object是安全的；需写入时应改用具体类型、有界通配符或泛型方法。
因为 List<?> 表示“一个元素类型为某个**未知但具体**的类型”的列表，编译器无法验证你添加的非 null 元素是否与那个隐藏的实际类型兼容——这是编译期强制执行的类型安全机制，不是疏漏，也不是运行时限制。
它不是“任意类型”，而是“某个未知的具体类型”
写 List<?> list = new ArrayList<String>();，并不等于说“这个列表能装任何东西”。它的真实含义是：这个列表的元素类型是某一个确定的类（比如 String），只是当前上下文**不知道它到底是哪一个**。编译器必须保证：无论实际类型是什么，你的操作都不能破坏类型契约。
所以当你调用 list.add("hello") 时，编译器会想：“如果实际类型其实是 Integer，那加字符串就完蛋了。” 它无法排除这种可能，因此直接禁止。
-
null是唯一被允许的例外，因为它是所有引用类型的合法值，不会导致类型不匹配 - 读取操作（如
list.get(0)）返回Object，是安全的——不管实际类型是什么，它一定是Object的子类
这不是 bug，是泛型设计的必然结果
Java 泛型在编译后会擦除类型信息，但编译器仍要靠静态检查守住类型安全底线。无界通配符放弃类型细节，换来的是最大兼容性（比如能接收 List<String>、List<Date> 等任意列表），代价就是写入能力归零。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
它适合的场景非常明确：
- 只调用
size()、isEmpty()、clear()这类不依赖元素类型的方法 - 遍历并统一处理为
Object（比如打印、序列化、判等） - 作为方法参数，表示“我不关心你存的是什么，我只做通用容器操作”
真要添加元素？换更合适的类型表达
如果你需要往列表里加东西，说明你其实**知道或可以约束元素类型**，那就不该用 List<?>：
- 确定是同一类对象 → 直接用
List<String>、List<Number> - 要接收多种子类型且只读 → 用
List<? extends Number> - 要往里塞
Integer及其子类 → 用List<? super Integer>（可 add，读取只能得Object） - 既要读又要写，又想保持泛型灵活性 → 改用泛型方法：
<T> void process(List<T> list)
捕获转换不是“绕过限制”的技巧
有人提到“捕获转换”（capture conversion），但它只是编译器内部临时给通配符起个名字（比如把 ? 当作 #1）来完成方法调用检查，并不开放给开发者使用。你不能声明 List<#1>，也不能靠它绕开 add 限制。试图用反射或强转硬塞，只会把问题拖到运行时，引发 ClassCastException。
