向下转型必须先用 instanceof 检查实际类型，否则运行时抛 ClassCastException；泛型擦除、接口多实现、外部输入等场景尤需谨慎，应优先用多态或类型化反序列化替代盲目强转。
向下转型前必须确认类型是否匹配
Java中向下转型（Child child = (Child) parent）不会在编译期报错，但运行时若 parent 实际不是 Child 类型或其子类，会抛出 ClassCastException。这不是设计缺陷，而是JVM对类型安全的强制校验。
常见错误现象：调用 instanceof 判定被跳过，或只检查了父类却忽略具体实现类；比如 Object obj = new ArrayList()，误判为 LinkedList 后强转，立即崩溃。
- 务必先用
obj instanceof TargetType检查，且TargetType必须是具体类或接口，不能是泛型擦除后的原始类型（如obj instanceof List编译不通过） - 如果对象来自外部输
入（如JSON反序列化、RPC响应），更不能假设类型——哪怕文档写明了，也要实测验证
- 注意数组类型也需单独判断：
obj instanceof String[]和obj instanceof Object[]行为不同，前者要求精确匹配
泛型集合向下转型极易出错
Java泛型在运行时被擦除，List 和 List 在JVM里都是 List，所以 (List 这种转型既不安全也不受编译器保护。
典型场景：从Spring RestTemplate 获取响应，声明为 List，实际数据结构却是嵌套的 Map，强行转成 List 会在后续取值时才暴露异常，堆栈信息难定位。
- 避免直接转型泛型集合，改用显式遍历+逐个转型：
list.stream().map(e -> (Child) e).collect(Collectors.toList()) - 使用
Gson或Jackson时，优先走类型化反序列化（如gson.fromJson(json, new TypeToken），而非先转- >(){}.getType())
Object再强转 - 若必须转型，加日志记录原始类名：
log.debug("Attempting cast to Child, actual class: {}", obj.getClass().getName())
接口引用向下转型要小心默认方法与多实现
当变量声明为接口类型（如 Runnable r = new MyTask()），向下转型到具体类（MyTask task = (MyTask) r）看似合理，但若该接口被多个类实现，且逻辑依赖具体实现细节，就容易漏掉边界情况。
例如 Comparable 接口被 String、Integer、自定义类同时实现，若代码中假定所有 Comparable 都能转成 String，就会在传入 Integer 时失败。
- 接口引用的向下转型，本质仍是基于运行时真实类型，和类继承链无关，所以
instanceof仍是最可靠判断手段 - 若涉及多个可能实现类，考虑用策略模式替代硬编码转型，把行为差异封装进接口方法里
- 注意接口默认方法不会影响转型结果，但可能掩盖类型不匹配问题——比如默认方法返回固定值，让人误以为转型成功
IDE和静态分析工具能发现部分问题但不可依赖
IntelliJ 能标出明显矛盾的转型（如 String s = (Integer) obj），但对运行时才确定类型的场景无能为力。SonarQube 的 S2179 规则可检测未检查的向下转型，但它只看语法结构，不分析控制流。
一个典型疏漏：在 try-catch 中捕获 ClassCastException 并吞掉异常，表面“兜底”了，实则掩盖了设计缺陷——本该用多态解决的问题，靠异常流程绕过去了。
- 把
instanceof+ 强转封装成工具方法（如castIfInstance(obj, Target.class)），避免重复写冗余判断 - 单元测试必须覆盖非预期类型路径，比如传入
null、父类实例、无关子类，验证是否按预期拒绝或处理 - 注意
Optional不是银弹：写成Optional.ofNullable(obj).filter(o -> o instanceof Child).map(o -> (Child) o)看似优雅，但没减少类型风险，只是延迟了异常抛出时机
向下转型本身不是坏味道，坏的是把它当成绕过类型系统的设计捷径。最隐蔽的坑往往不在转型那一行，而在上游数据来源缺乏契约约束——比如DAO层返回 Object，却指望Service层靠猜来转型。
