ClassCastException在运行时抛出，因强制类型转换不检查实际类型；基本类型转换可能静默丢失精度或溢出；泛型擦除使转换看似合法实则危险；应优先用instanceof预检、泛型安全设计及单元测试保障。
ClassCastException 会在运行时突然爆发
Java 的强制类型转换（(TargetType) object）不会在编译期检查实际类型是否兼容，只看引用声明类型和目标类型是否有继承/实现关系。一旦实际对象不是目标类型或其子类，JVM 就抛 ClassCastException。
- 常见错误场景：从
Object集合里取元素后直接强转，比如List存了String和Integer，遍历时统一转String - 泛型擦除加剧风险：编译器无法阻止你写
(String) list.get(1)，即使list实际存的是Double - 避免方式：转换前用
instanceof预检（注意 null 安全），或改用更安全的封装逻辑（如自定义 getter、Optional 包装）
数值类型强制转换可能丢失精度或溢出
基本类型间强制转换（如 (int) doubleValue 或 (byte) intValue）不报错也不提示，但行为是截断或模运算，极易引入静默 bug。
-
(int) 3.9→ 得到3（非四舍五入） -
(byte) 200→ 得到-56（超出 byte 范围 [-128, 127]，高位截断） -
(short) Integer.MAX_VALUE→ 得到-1（32 位 int 截成 16 位 short） - 建议：涉及精度敏感场景（金融、计时），优先用
Math.round()、BigDecimal或明确范围校验；必要时加注释说明截断意图
泛型类型擦除导致强制转换「看似合法却必崩」
Java 泛型在运行时不存在类型信息，(List 这种转换编译能过，但若 obj 实际是 ArrayList，运行时不会立即失败——直到你调用 get(0) 并尝试当作 String 用，才爆 ClassCastException。
- 典型陷阱：
return (List—— T 在运行时是) new ArrayList(); Object，返回列表实际元素类型不受约束 - 反射场景更危险：用
Method.invoke()返回值强转泛型类型，同样无运行时保障 - 缓解手段：用
@SuppressWarnings("unchecked")时必须配套单元测试覆盖真实数据流；优先用工厂方法或类型令牌（TypeReference类）保留信息
父类引用转子类时，方法调用可能违反 LSP 原则
即使 instanceof 检查通过，强制转为子类后调用子类特有方法，也可能掩盖设计缺陷：比如本该用多态解决的行为差异，却被硬编码为「先判断再强转」。
立即学习“Java免费学习笔记（深入）”；
- 反模式示例：
if (obj instanceof Dog) { ((Dog) obj).bark(); } else if (obj instanceof Cat) { ((Cat) obj).meow(); }—— 这应由接口方法统一抽象 - 维护隐患：每新增一个子类，都要补一堆
instanceof分支，违背开闭原则 - 真正需要强转的合理场景极少，常见于框架回调（如 Spring 的
BeanFactory）、序列化反解、或遗留系统适配——此时务必确保转换链可控且有日志兜底
最易被忽略的一点：IDE 和静态分析工具（如 SpotBugs）对强转警告默认不开启或不够激进，而线上 ClassCastException 往往出现在低频分支或特定数据组合下，很难靠测试全覆盖。别依赖「没报错就等于安全」。
