java强制类型转换异常源于运行时类型不兼容，需用instanceof校验后再转换；字符串转数值须调用parsexxx方法并捕获numberformatexception；泛型应避免原始类型声明；多态设计优于硬编码转型。
Java强制类型转换引发的运行时异常，本质是对象实际类型与目标类型不兼容。这类问题不会在编译时报错，却会在执行到转换语句时突然抛出 ClassCastException，导致逻辑中断甚至服务崩溃。关键不是“能不能转”，而是“该不该转”和“有没有保障”。
用 instanceof 提前校验再转换
直接写 (Dog) animal 风险极高——只要 animal 实际不是 Dog 类型，立刻失败。正确做法是先判断、再转换：
- 写法示例：
if (obj instanceof Dog) { Dog dog = (Dog) obj; } -
instanceof对null返回false，天然安全，无需额外判空 - 注意：它检查的是运行时真实类型，不是变量声明类型（比如
Animal a = new Cat()，a instanceof Dog就是false）
字符串转数值必须用解析方法
Java 不允许 (int) "123" 这种语法，编译就报错。字符串和基本类型/包装类之间没有继承关系，也不能强转。
- 整数转换用
Integer.parseInt("123")或Integer.valueOf("123") - 浮点数用
Double.parseDouble("3.14") - 务必加
try-catch捕获NumberFormatException，避免流程中断
泛型擦除场景要严防集合取值误转
像 List list = new ArrayList<string>()</string> 这种原始声明，编译能过，但运行时类型信息已丢失。往里混入 Integer 后，(String) list.get(0) 就会出错。
- 始终使用带泛型的声明：
List<string> list = new ArrayList()</string> - 从集合取值后，仍需
instanceof校验，不能凭经验假设类型 - 更稳妥的做法：用
stream.filter(...).map(...)提前过滤非目标类型
多态设计优先替代硬编码转型
频繁靠 instanceof + 强转 分支处理不同子类，说明设计可能有问题。
- 把行为抽象成接口或父类方法（如
void process()），让各子类自己实现 - 避免在调用方写一堆
if (x instanceof A) {...} else if (x instanceof B) {...} - 这样既消除转型风险，又符合开闭原则，后续新增子类也不用改原有逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
