Java类型转换存在多重运行时风险：基本类型强制转换静默丢失精度与溢出；引用类型向下转型易抛ClassCastException；泛型擦除导致“伪安全”转换；boolean与String等不可转换类型强转必崩。
Java 类型转换看似简单，实则暗藏多重运行时与逻辑风险。真正影响系统稳定性的，往往不是编译失败，而是那些“能过编译却悄悄出错”的转换行为。
基本类型强制转换：静默丢失精度与溢出
基本类型间强制转换不报错、不警告，但结果可能完全偏离预期。核心问题是二进制截断而非四舍五入，且溢出遵循模运算规则。
- (int) 3.9 得到 3 —— 小数部分直接丢弃，不是舍入；金融计算中若误用，会导致金额持续少计
- (byte) 200 得到 -56 —— byte 范围是 -128～127，200 超限后高位截断，等价于 200 % 256 再按补码解释
- (short) Integer.MAX_VALUE（2147483647）得到 -1 —— 32 位 int 强转为 16 位 short，仅保留低 16 位，原值二进制低 16 位全为 1，解释为有符号 short 即 -1
建议：涉及金额、计时、ID 等敏感场景，优先使用 Math.toIntExact()（溢出会抛 ArithmeticException），或用 BigDecimal 控制精度。
引用类型向下转型：ClassCastException 隐形炸弹
父类引用转子类（downcasting）必须确保实际对象是目标类型或其子类，否则 JVM 在运行时抛 ClassCastException，且编译器无法提前拦截。
立即学习“Java免费学习笔记（深入）”；
- 常见高危场景：从
List<object></object>或Map<string object></string>中取值后直接强转，如(String) map.get("status")，而实际存入的是Boolean - 泛型擦除加剧风险：
(List<string>) list</string>编译通过，但若list实际是ArrayList<integer></integer>，后续调用get(0)才崩溃 -
instanceof是必要防线，但需注意null返回false，应单独判空避免混淆异常根源
安全写法示例：
if (obj != null && obj instanceof String) {<br> String s = (String) obj;<br>}
集合与泛型转换：类型擦除导致的“伪安全”
Java 泛型在运行时被擦除，所有参数化类型都退化为原始类型。这使得很多看似合理的强制转换在逻辑上无效，却能编译通过。
-
List<string> list = (List<string>) new ArrayList();</string></string>编译警告 “unchecked”，运行时无保障；若向其中 add(123)，取值时才爆异常 -
Set>不能强转为List>—— 二者无继承关系，HashSet不实现List接口，运行时报ClassCastException - 正确做法是构造新容器：
new ArrayList(set)，而非类型转换
规避策略：用工厂方法封装、引入 TypeReference（如 Jackson）、对泛型返回值做单元测试覆盖真实数据流。
布尔与字符串等不可转换类型：强转必崩
Java 明确禁止 boolean 与 String、数值类型之间的任何形式的强制转换。这类错误通常出现在 JSON 解析、数据库字段映射或动态集合操作中。
- 典型错误：
String s = (String) true;或boolean b = (boolean) "true";—— 直接抛ClassCastException - JSON 场景中，Jackson 默认将 boolean 字段序列化为
true/false，若前端传字符串"true"而后端未配置反序列化器，解析失败 - 安全替代：用
String.valueOf(boolean)、Boolean.parseBoolean(String)，或借助Optional.ofNullable(obj).filter(Boolean.class::isInstance).map(Object::toString).orElse("false")
