ClassCastException总在运行时抛出，因泛型擦除后编译器无法阻止非法向下转型；Collections.checkedList通过动态拦截写操作并校验元素类型提供安全防护，但需在填充数据前使用且要求底层集合可修改。
向下转型集合时ClassCastException总在运行时才爆？
Java泛型擦除后，编译器无法阻止你把ArrayList<string></string>强制转成ArrayList<integer></integer>——但一调用get(0)就崩。这不是“写法错”，是泛型设计本就不防这种转型。真正能拦住它的，只有运行时检查机制。
别指望(ArrayList<integer>) list</integer>加个@SuppressWarnings("unchecked")就万事大吉。它只是让编译器闭嘴，问题照旧。
- 所有原始类型集合（如
ArrayList、LinkedList）都支持向下转型，但无任何类型保护 - 泛型通配符
?或? extends T只能读不能写，根本没法用来接收转型后的引用 - 如果目标是“允许写入但确保类型安全”，必须引入动态检查层
Collections.checkedList为什么比手写包装更可靠？
Collections.checkedList不是简单套壳，它在每次add、set、addAll甚至listIterator()返回的迭代器上都插了类型校验。它不碰原始集合结构，只拦截写操作。
注意：它只检查写入元素类型，不校验已有元素——所以必须在集合初始化后、填入数据前就套上。
立即学习“Java免费学习笔记（深入）”；
- 传入的原始集合必须是可修改的（
Arrays.asList()返回的不行，会抛UnsupportedOperationException） - 检查逻辑基于
Class.isInstance()，对基本类型包装类（如int→Integer）有效，但对泛型嵌套（如List<string></string>）只校验外层List，不深入 - 性能开销极小，一次
add多一次instanceof判断，远低于反射或自定义代理
示例：
List<String> raw = new ArrayList<>();
List<String> safe = Collections.checkedList(raw, String.class);
safe.add("ok"); // ✅
safe.add(123); // ❌ ClassCastException at runtime
泛型通配符? super T能替代checkedList吗？
不能。通配符解决的是**方法参数协变/逆变**问题，不是运行时类型防护。比如你写一个接受List super Number>的方法，它确实能收ArrayList<object></object>或ArrayList<number></number>，但一旦你拿到这个引用，能做的只有add(Number)——而且加进去什么，全靠你自己保证。
它不阻止你后续把这列表转成ArrayList<string></string>再强转回去；也不阻止你在别的地方往原始列表里塞错类型。
-
? super T只约束“你能往里写什么”，不限制“别人往里写了什么” - 它没有运行时痕迹，擦除后就是裸
List，和checkedList的防御层级完全不同 - 混用会导致类型推导失败，比如
Collections.checkedList(list, String.class)返回的是List<string></string>，不是List super String>
checkedList的坑：包装后别直接暴露原始引用
这是最常被忽略的一点：Collections.checkedList返回的是一个包装视图，原始集合仍可被绕过检查直接操作。
如果你把原始ArrayList还存着、或者被其他代码持有，那所有检查形同虚设。
- 务必丢掉原始引用，只保留checkedList返回的引用
- 如果集合来自外部（比如DAO返回的
List），先复制一份再包装：Collections.checkedList(new ArrayList(source), String.class) - 不要对checkedList结果再做
(ArrayList)强转——它实际是CheckedList内部类，强转会失败
复杂点在于：检查只发生在写入路径，读取永远畅通。所以类型错误可能藏在上游——比如从JSON反序列化来的List，本身元素就是混的，checkedList拦不住。
