Collections.checkedMap仅校验key类型，不检查value类型；它在put等写操作时用key.getClass()匹配指定keyType，value完全透传， valueType参数仅用于记录而未参与运行时校验。
Collections.checkedMap 不能拦截“非法类型元素”，因为它根本不管元素（value）类型——它只校验 键（key） 的类型。这是它和 checkedList / checkedSet 最关键的区别，也是开发者最容易误用的地方。
checkedMap 只检查 key，不检查 value
Java 的 Collections.checkedMap 返回一个运行时包装器，其核心逻辑是：在 put、putAll 等写入操作中，仅对传入的 key 参数 做 getClass() 精确匹配校验；而 value 完全透传，不做任何类型检查。
例如：
- ✅ safeMap.put("user1", new Integer(100)) —— key 是 String，合法；value 是 Integer，不校验，允许
- ❌ safeMap.put(123, "ok") —— key 是 Integer，与指定的 String.class 不匹配，立即抛 ClassCastException
这说明：如果你期望靠 checkedMap 防止 map 中混入错误类型的 value（比如本该是 User 却塞进 String），它做不到——value 类型安全需靠其他手段保障。
立即学习“Java免费学习笔记（深入）”；
为什么 value 不被检查？设计使然
checkedMap 的签名是：Collections.checkedMap(Map<K,V> m, Class<K> keyType, Class<V> valueType)
注意：它确实接收了 valueType 参数，但JDK 源码中该参数仅用于构造时记录，并未在任何 put 方法中使用。官方文档也明确说明：“value type is not checked”。这是历史设计决定的——map 的 value 类型通常更动态、更难统一约束（比如缓存场景中 value 可能是多种 POJO），所以只聚焦 key 的一致性。
想真正约束 value？得组合其他手段
若业务要求 key 和 value 都强类型，不能只靠 checkedMap。可行方案包括：
- 自定义包装类：继承 AbstractMap 或封装 HashMap，在 put 里手动校验 key 和 value 的 getClass()
- 使用泛型友好的不可变容器（如 Guava 的 ImmutableMap.Builder），配合编译期泛型约束
- 配合 CheckedCollection 包装 value 集合：例如 value 是 List
，可用 Collections.checkedList 包装该 list 实例，再 put 进 map - 在 DAO 或 service 层做统一校验：用 instanceof 或 Class.isInstance() 在入库前拦截非法 value
绕过 checkedMap 的常见失效场景
即使正确使用 checkedMap，仍可能失效，原因和 checkedList 类似：
- 持有原始 Map 引用（如底层是 HashMap），并直接调用它的 put 方法 → 绕过所有检查
- 通过反射修改内部 map → 检查完全失效
- putAll 传入一个已含非法 key 的 map → checkedMap 会逐个校验每个 entry 的 key，但若源 map 是原始类型且含错 key，会在 putAll 过程中当场失败，不是“事后爆发”
所以必须确保：所有写入操作都只通过 checkedMap 引用进行，且不暴露底层 map。
