ClassCastException 根源在于未验证的向下转型，而非多态本身；应通过静态分析标记裸强转、封装可验证的类型转换方法、在反序列化阶段绑定真实类型、使用 Collections.checkedList 在写入侧设防。
多态本身不引发 ClassCastException，问题出在向下转型（downcasting）时绕过类型校验。静态检查不能替代运行时判断，但能提前暴露高风险转型点——关键不是“拦住所有转型”，而是让每次转型都可验证、可追溯、有上下文。
用 IDE 和静态分析工具标记可疑强转
现代 IDE（IntelliJ、Eclipse）默认会高亮无 instanceof 保护的裸强转，比如 (String) obj 或 (User) list.get(0)。启用 SpotBugs、Error Prone 或 SonarQube 的以下规则可自动识别：
- BC_UNCONFIRMED_CAST（SpotBugs）：检测未被 instanceof 或 Class.isInstance() 验证的强制转换
- CheckCast（Error Prone）：标记可能失败的 cast，尤其在泛型擦除后对原始集合元素的转型
- 自定义规则：扫描 Object、Map<?, ?>、List<?> 等通配集合的 get() 后直接强转语句
把转型逻辑收进带类型契约的工具方法
避免散落在业务代码里的裸强转。统一用封装方法替代，例如：
-
safeCast(obj, String.class)：内部调用
String.class.isInstance(obj)，失败抛含堆栈和输入值的 RuntimeException - getAsString(map, "name")：先判 key 是否存在，再判 value 是否为 String，否则返回 null 或 throw TypedValueException
-
filterAndCast(list, Integer.class)：返回
list.stream().filter(Integer.class::isInstance).map(Integer.class::cast).toList()
这些方法本身可被静态分析覆盖，调用处也更易审计——所有外部输入（JSON 解析结果、RPC 响应、数据库字段）必须走这些入口。
立即学习“Java免费学习笔记（深入）”；
泛型反序列化阶段就绑定真实类型
ClassCastException 很多源于 JSON 或 RPC 返回的 List<Object> 被当成 List<User> 使用。静态检查无法修复运行时擦除，但可通过强制定型把问题左移到解析环节：
- Jackson：不用
mapper.readValue(json, List.class)，改用mapper.readValue(json, new TypeReference<List<User>>() {}) - Gson：不用
gson.fromJson(json, List.class)，改用gson.fromJson(json, TypeToken.getParameterized(List.class, User.class).getType()) - 开启 Jackson 的
@JsonTypeInfo多态反序列化校验，防止子类误解析为父类
用 Collections.checkedList 在写入侧设防
对需长期持有并反复读取的集合，可在初始化时加运行时类型护栏：
List<String> safeList = Collections.checkedList(new ArrayList<>(), String.class);- 后续
safeList.add(123)会立即抛 IllegalArgumentException，而非等到某处(String) safeList.get(0)才崩 - 注意：只防护新增/修改，不校验已有元素；不可用于 Arrays.asList() 等不可变集合
