ClassCastException是引用类型强制转换的最大隐患，因Java编译期仅检查声明类型关系、运行时才校验实际类型；基本类型强转静默丢失数据更危险；泛型擦除导致“伪安全”转型；设计上应减少强转，多用多态、契约与抽象。
引用类型强制转换：ClassCastException 是最大隐患
Java 不会在编译期验证对象实际类型，只检查声明类型与目标类型是否存在继承或实现关系。一旦运行时对象真实类型不匹配，立刻抛出 ClassCastException。
典型场景包括：从 Object 数组或原始集合中取值后直接强转、泛型擦除后对返回值盲目转型、反射调用方法后未经校验就转为具体类型。
- 安全做法是先用
instanceof判断——但注意它对null返回false，需单独处理空值 - 若逻辑允许，优先用多态替代类型判断，比如定义统一接口方法，避免
if (x instanceof A) { ((A)x).doA(); } else if (x instanceof B)...这类扩展性差的写法 - 对无法避免的转型，可配合
Optional封装，或使用工具类（如 Apache Commons Lang 的ObjectUtils）提供带校验的转换方法
基本类型强制转换：静默丢失比报错更危险
基本类型间强转不会抛异常，但会无提示地截断、溢出或舍入，结果不可逆且难以排查。
例如：(int)3.9 得到 3（非四舍五入），(byte)200 得到 -56（超出范围后按模运算），(short)Integer.MAX_VALUE 得到 -1（高位被丢弃）。
立即学习“Java免费学习笔记（深入）”；
- 涉及金额、时间戳等敏感数据时，禁用裸强转，改用
Math.toIntExact()、BigDecimal或显式范围校验 - 混合运算中注意类型提升规则：
byte/short/char参与运算自动升为int，结果赋值回小类型必须显式强转 - 浮点转整数前，明确业务意图是截断还是四舍五入——前者用强转，后者用
Math.round()
泛型擦除带来的“伪安全”陷阱
泛型仅在编译期存在，运行时已擦除为原始类型。这导致某些看似合法的强转能通过编译，却在真正使用元素时才崩溃。
比如 (List<string>) new ArrayList<integer>()</integer></string> 编译能过，但调用 get(0) 后转成 String 就会爆 ClassCastException；又如 return (List<t>) new ArrayList()</t>，T 在运行时就是 Object，完全失去类型约束。
- 禁止对泛型参数化类型做显式强转，尤其避免
@SuppressWarnings("unchecked")滥用 - 需要保留泛型信息时，用
TypeReference（如 Jackson）、类型令牌或工厂方法封装 - 单元测试必须覆盖真实数据流，验证泛型容器中存取的确实是预期类型
设计层面规避：少用强转，多靠契约与抽象
频繁依赖强转往往反映设计问题：职责不清、抽象不足、类型边界模糊。
比如父类引用频繁向下转型调用子类特有方法，说明本该由接口或抽象方法统一行为；又如用 Object 作为通用容器传递多种类型，不如拆分为专用 DTO 或引入密封类（Sealed Classes）限定可能类型。
- 用枚举或记录类（Record）替代字符串/数字编码的“伪类型”
- 对外暴露 API 时，优先返回不可变集合、封装后的视图对象，而非原始类型或泛型裸类型
- 借助 IDE 实时检查和静态分析工具（如 ErrorProne、SonarQube）提前发现高风险转换代码
