Collections.checkedCollection仅在写入时检查类型，不干预读取，且无法防止绕过代理直接操作底层集合、反射修改或传入错误Class参数导致的类型失效，也不检查null值。
为什么 Collections.checkedCollection 不能阻止所有类型错误
它只在「写入时」做类型检查，不干预读取；一旦绕过包装对象直接操作底层集合，类型安全就彻底失效。比如你把 checkedCollection 返回的代理对象转成原始 ArrayList 后 add，或者用反射修改，检查就形同虚设。
- 检查仅发生在
add、addAll、set等写操作入口，get和迭代器遍历完全不校验 - 返回的是
Collection接口实现，无法防止向下转型后绕过检查 - 泛型擦除后运行时无类型信息，它依赖你传入的
Class参数做instanceof判断——如果传错（比如传Number.class却往里塞String），照样报ClassCastException
Collections.checkedCollection 的正确初始化姿势
必须确保：包装对象是唯一访问入口，且 Class 参数与实际期望元素类型严格一致。常见错误是传了父类类型（如 Object.class）或接口（如 List.class），导致检查失效。
- ✅ 正确：
Collections.checkedCollection(new ArrayList<String>(), String.class) - ❌ 错误：
Collections.checkedCollection(new ArrayList<>(), Object.class)（失去检查意义） - ❌ 错误：
Collections.checkedCollection(new ArrayList<Integer>(), Number.class)（Number.class允许Double、BigInteger等，但你可能只想要Integer） - ⚠️ 注意：传入的原始集合不能是已含非法元素的，否则构造时不检查，首次写入前就读到脏数据
和 Arrays.asList + 泛型声明混用会出什么问题
很多人想“省事”把 Arrays.asList("a", "b") 直接喂给 checkedCollection，结果发现编译能过、运行时报 UnsupportedOperationException——因为 Arrays.asList 返回的是不可变大小的内部列表，checkedCollection 包装后仍继承其限制。
-
add、remove、clear会抛UnsupportedOperationException，不是类型问题，是结构问题 - 解决办法：显式 new 一个支持增删的集合，如
new ArrayList<>(Arrays.asList(...)) - 别依赖 IDE 自动补全的泛型推导，手动写明类型参数更安全，例如
new ArrayList<String>(Arrays.asList("a", "b"))
替代方案：什么时候该放弃 checkedCollection，改用其他手段
它适合临时兜底、测试场景或遗留代码改造；但项目长期维护中，静态类型检查（IDE + 编译器）+ 不可变集合（ImmutableList）+ 构造期校验才是更稳的组合。动态检查只是最后一道沙袋，不是防洪大坝。
立即学习“Java免费学习笔记（深入）”；
- 如果你控制不了集合创建位置（比如从三方库接收），
checkedCollection是低成本防御手段 - 如果集合生命周期长、多线程访问，它不提供线程安全，得额外套
Collections.synchronizedCollection，但注意双重包装的开销和锁粒度 - Guava 的
ImmutableList.copyOf或Lists.newArrayList配合构造函数校验，往往比运行时检查更早暴露问题
真正容易被忽略的是：checkedCollection 不检查 null ——除非你显式在 add 前自己判空。它只管类型，不管值语义。
