Collections.checkedSet()仅在正常调用add等方法时做运行时类型检查，无法防止反射绕过；反射可直接操作底层集合或修改内部字段，导致非法数据插入，后续取用时才抛异常；它不是安全机制，仅适用于可信环境下的误用防护。
Collections.checkedSet() 无法防止反射绕过泛型检查插入非法数据，它根本不是为此设计的。
checkedSet 的真实作用：运行时类型检查（仅限“正常”添加操作）
它返回一个包装过的 Set，在每次调用 add()、addAll()、retainAll() 等修改方法时，**检查传入元素是否为声明的泛型类型**。如果类型不匹配，抛出 ClassCastException。
但它对以下情况完全无能为力：
- 通过反射直接访问底层集合（如获取被包装的原始
HashSet并调用其add()） - 通过反射修改包装器内部字段（如替换其持有的类型信息或委托集合）
- 利用泛型擦除，在字节码层面构造非法对象并插入（JVM 层面已允许）
为什么反射能轻易绕过 checkedSet？
checkedSet 是一个轻量级装饰器，它本身不改变 JVM 的类型系统，也不阻止反射访问其私有字段或底层集合。例如：
Set<String> safe = Collections.checkedSet(new HashSet<>(), String.class);
// 正常调用会被拦截
// safe.add(123); // ClassCastException
// 但反射可以直达底层
Field field = safe.getClass().getDeclaredField("s"); // 假设底层字段名是 "s"
field.setAccessible(true);
Set rawUnderlying = (Set) field.get(safe);
rawUnderlying.add(123); // 成功！此时 safe 中实际含 Integer
一旦非法对象进入集合，后续遍历时取出来就会在取用处而非插入处抛异常，失去防护意义。
真正需要防范反射绕过？现实方案很有限
Java 没有机制能完全禁止反射破坏封装——这是语言设计权衡的结果。可行思路只有：
- 信任边界内不暴露可反射的敏感引用：避免将 checkedSet 返回值传给不可信代码；不要把包装后的集合再暴露其 getClass() 或字段信息
-
使用不可变集合（更可靠）：如
Set.copyOf()（Java 10+）或ImmutableSet（Guava），它们在构建后拒绝任何修改，反射也无法“安全地”修改内部状态（多数实现用 final 字段 + 私有构造） -
自定义强校验容器（复杂且不推荐）：如用
sun.misc.Unsafe锁定内存布局（已废弃）、或依赖 SecurityManager（Java 17+ 默认移除），均非标准、可移植方案
总结：checkedSet 是“善意提醒”，不是“安全围栏”
它适合用于开发阶段捕获误用（比如自己写错 add 类型），或在可信上下文中防御粗心错误。但绝不能用于对抗恶意反射、沙箱逃逸或安全敏感场景。需要强类型保障，请优先考虑不可变集合 + 编译期检查 + 模块化封装。
