list禁止添加非null元素是编译期类型安全机制，因其表示“未知但具体”的类型，编译器无法验证添加元素的兼容性；null被允许因它是所有引用类型的合法值；读取返回object是安全的；需写入时应改用具体类型、有界通配符或泛型方法。
因为 List> 表示“一个元素类型为某个**未知但具体**的类型”的列表，编译器无法验证你添加的非 null 元素是否与那个隐藏的实际类型兼容——这是编译期强制执行的类型安全机制，不是疏漏，也不是运行时限制。
它不是“任意类型”，而是“某个未知的具体类型”
写 List> list = new ArrayList<string>();</string>，并不等于说“这个列表能装任何东西”。它的真实含义是：这个列表的元素类型是某一个确定的类（比如 String），只是当前上下文**不知道它到底是哪一个**。编译器必须保证：无论实际类型是什么，你的操作都不能破坏类型契约。
所以当你调用 list.add("hello") 时，编译器会想：“如果实际类型其实是 Integer，那加字符串就完蛋了。” 它无法排除这种可能，因此直接禁止。
-
null是唯一被允许的例外，因为它是所有引用类型的合法值，不会导致类型不匹配 - 读取操作（如
list.get(0)）返回Object，是安全的——不管实际类型是什么，它一定是Object的子类
这不是 bug，是泛型设计的必然结果
Java 泛型在编译后会擦除类型信息，但编译器仍要靠静态检查守住类型安全底线。无界通配符放弃类型细节，换来的是最大兼容性（比如能接收 List<string></string>、List<date></date> 等任意列表），代价就是写入能力归零。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
它适合的场景非常明确：
- 只调用
size()、isEmpty()、clear()这类不依赖元素类型的方法 - 遍历并统一处理为
Object（比如打印、序列化、判等） - 作为方法参数，表示“我不关心你存的是什么，我只做通用容器操作”
真要添加元素？换更合适的类型表达
如果你需要往列表里加东西，说明你其实**知道或可以约束元素类型**，那就不该用 List>：
- 确定是同一类对象 → 直接用
List<string></string>、List<number></number> - 要接收多种子类型且只读 → 用
List extends Number> - 要往里塞
Integer及其子类 → 用List super Integer>（可 add，读取只能得Object） - 既要读又要写，又想保持泛型灵活性 → 改用泛型方法：
<t> void process(List<t> list)</t></t>
捕获转换不是“绕过限制”的技巧
有人提到“捕获转换”（capture conversion），但它只是编译器内部临时给通配符起个名字（比如把 ? 当作 #1）来完成方法调用检查，并不开放给开发者使用。你不能声明 List，也不能靠它绕开 add 限制。试图用反射或强转硬塞，只会把问题拖到运行时，引发 ClassCastException。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
