必须先用 instanceof 判断再强转，否则必抛 classcastexception；jdk14+ 可用模式匹配简化，但泛型擦除、反射、序列化等场景仍需谨慎判型。
Java 中 instanceof 不写就直接 (SubType) 强转？大概率崩
不检查类型就强转，ClassCastException 是板上钉钉的事。这不是“可能出错”，而是“只要运行到那行，且对象不是目标类型，立刻抛异常”。JVM 不会帮你兜底，它只认字节码里的类型断言。
常见错误现象：java.lang.ClassCastException: java.lang.String cannot be cast to com.example.User —— 这种报错往往出现在从 Object 集合取值、反序列化泛型擦除后、或处理多态返回结果时。
- 必须先用
instanceof判断，再转型；JDK 14+ 可用模式匹配（if (obj instanceof SubType s)），但老项目仍以传统方式为主 - 泛型集合如
List<object></object>存了混合类型，取出来直接(User)就是高危操作 - Spring 的
BeanFactory.getBean()返回Object时，也得自己判型，别信 IDE 自动补全的强转
ClassCastException 真的只发生在运行时？编译器不管吗
编译器只看引用类型，不看实际对象。比如 Object obj = new String("a");，编译器认为 obj 是 Object，你写 (Integer) obj 它照常过——因为语法合法：父类引用可以尝试转成任意子类（哪怕八竿子打不着）。
真正拦不住，是因为 Java 的向下转型是动态检查。这也是为什么泛型擦除后，List<string></string> 和 List<integer></integer> 在运行时都是 List，加了 (Integer) 强转，只要里面塞的是 "123"，照样崩。
- 编译期不会报错 ≠ 安全；它只是放行“看起来可能成立”的转换
-
final类（如String）被转成非父子关系类型时，部分 JDK 版本会在编译期警告，但不阻止 - IDE 的静态检查（如 IntelliJ 的 inspection）能标红可疑强转，但依赖代码可分析性，不能替代运行时防护
用 Optional 或 try-catch 捕获 ClassCastException？别这么干
捕获 ClassCastException 属于典型的“用异常流控”，性能差、掩盖设计问题。它本不该发生——类型不匹配是逻辑缺陷，不是临时性故障。
典型误用场景：从 JSON 反序列化得到 Map<string object></string>，然后对某个字段反复 try-catch 转 String/Long/Boolean……这说明数据契约没对齐，或者该用更严格的解析方式（如 Jackson 的 @JsonSubTypes 或自定义 Deserializer）。
-
Optional.ofNullable(obj).map(o -> (SubType) o).orElse(null)看似优雅，实则把运行时风险藏得更深，且没解决根本判型问题 -
catch (ClassCastException e)会让调用方无法区分“数据错”和“程序错”，日志里只剩一串堆栈，查因成本飙升 - 真要兜底，应在上游做类型校验（如 JSON Schema、Protobuf schema），而不是下游靠 catch 救火
向下转型在泛型、反射、序列化里特别容易翻车
泛型擦除、反射绕过编译检查、序列化还原对象类型丢失——这三块是 ClassCastException 的重灾区，因为它们天然削弱了类型信息。
比如用 ObjectInputStream.readObject() 读一个本该是 User 的对象，如果 classpath 里没有对应类，或版本不一致，可能还原成 java.util.LinkedHashMap，此时再强转 User，崩得无声无息。
- 反射调用
Method.invoke()返回Object，别图省事直接(YourType)，先result.getClass().isAssignableFrom(YourType.class) - Gson 默认把 JSON 数组解析为
ArrayList<linkedtreemap></linkedtreemap>，不是你写的List<user></user>，得配TypeToken或自定义Adapter - Android 的
Parcelable如果CREATOR写错类名，也会在createFromParcel后强转时报错，且堆栈极难定位
最麻烦的不是崩，而是崩得晚——可能在 UI 层点某个按钮才触发，而问题根源在初始化时的数据加载环节。这类延迟暴露的类型错配，调试起来最耗神。
