为什么 Java 编译器不允许向 List 添加非 null 值？这背后隐藏着一个关键的类型安全设计——它只允许 add(null)，因为 null 是唯一无需类型校验的“通用值”，这也恰好符合 PECS 原则中“只读”的语义。
` 限制了只能 add `null`">
核心原因在于：编译器无法确定实际容器究竟能容纳哪种具体子类型，因此只能保守地放行一个在所有引用类型中都绝对安全的特殊值——null。
编译器无法确定真实类型，只能采取保守限制
当你声明 List 时，这个变量可能指向 ArrayList、ArrayList 或 ArrayList 中的任意一个。编译器只知道元素是 Number 的某个子类，但具体是哪个子类？它无法确定。
- 如果底层实际是
ArrayList，你尝试add(1.0)（一个Double）将直接破坏类型一致性。 - 如果底层实际是
ArrayList，你尝试add(42)（一个Integer）同样会引发类型错误。 - 为了避免这类运行时灾难，编译器必须一刀切：禁止所有可能违法的写入操作。因此，除了
null之外，其他值一律不允许add。
null 是唯一无需类型校验的“通用值”
null 不携带任何类型信息，在 Java 中它可以赋给任意引用类型变量，不会引发类型冲突。所以 list.add(null) 总是合法的——无论底层是 ArrayList 还是 LinkedList，null 都能顺利存入。而其他值都有明确的类型，通配符上限提供的信息不足以让编译器验证其兼容性。
这不是缺陷，而是类型安全的设计选择
PECS 原则将“只读”语义编码进了类型系统：? extends T 明确表示“这个集合用于产出 T 或其子类实例”，而不是用来接收外部输入。如果你确实需要往集合中添加数据，就应该使用 ? super T —— 它告诉编译器“我保证只存入 T 及其子类”。如果既有读又有写的需求，那就直接用具体类型，比如 List，或者通过泛型方法
本质上，不允许添加非 null 值，就是为了把潜在的运行时类型错误提前拦截在编译期。这才是真正的安全设计。
