ClassCastException 在向下转型时抛出，因编译期只检查引用类型而运行期才验证实际对象类型；若实际类型不匹配目标子类，JVM 即抛异常。
为什么 ClassCastException 在向下转型时才抛出
因为 Java 的向上转型（比如 Object obj = new String("a")）永远安全，编译器允许且运行时不会检查；但向下转型（比如 String s = (String) obj）是“你保证它本来就是这个类型”，JVM 会在运行时验证——验证失败就抛 ClassCastException。
关键点：编译期只看引用类型，运行期才看真实对象类型。如果引用类型是父类，但实际对象不是目标子类，强转就崩。
- 常见错误现象：
ClassCastException: java.lang.Integer cannot be cast to java.lang.String - 典型场景：从
Collection或Map取值后直接强转，没确认实际类型（尤其混存多种类型时） - 参数差异：和
instanceof不同，(TargetType) obj不做类型检查，只信你
怎么安全地做向下转型
核心原则：先用 instanceof 守住底线，再转。这不是多此一举，是避免崩溃的最小成本。
if (obj instanceof String) {
String s = (String) obj;
// 安全使用 s
}
- 注意：Java 14+ 支持模式匹配（
if (obj instanceof String s)），一步完成检查+赋值，但老版本必须分开写 - 不能只靠 try-catch 捕获
ClassCastException来“兜底”——异常开销大，且掩盖了设计问题 - 泛型能从源头规避大部分向下转型需求，比如用
List<String>而非List
哪些情况看似合理却仍会触发 ClassCastException
表面看类型匹配，实则因类型擦除、代理、动态生成类等机制导致运行时类型不一致。
立即学习“Java免费学习笔记（深入）”；
-
ArrayList<String>转成ArrayList<Integer>：泛型擦除后都是ArrayList，但元素类型不兼容，强转引用无意义，取值时才爆错 - Spring AOP 代理对象：接口类型引用指向的是
$Proxy类实例，若误转为具体实现类（如(ServiceImpl) service），必抛异常 - JSON 反序列化用
ObjectMapper.readValue(json, Object.class)后，得到的是LinkedHashMap，不是你预期的某个 DTO 类
替代强转的更健壮做法
真正要解决的不是“怎么转得更小心”，而是“为什么需要转”。多数时候，重构比加 instanceof 更治本。
- 用泛型明确约束：把
List list改成List<User> users - 用 sealed class（Java 17+）或枚举限定可能子类，配合 switch + pattern matching 消除不确定分支
- 对第三方 API 返回的
Object，第一时间封装成明确类型（比如写个fromJson(String, Class<T>)工具方法），别让Object流到业务逻辑深处
最常被忽略的一点：很多 ClassCastException 其实源于测试数据构造错误——比如单元测试里传了个 new Integer(1) 进本该接收 String 的方法，问题不在转型逻辑，而在输入契约没对齐。
