类型转换中的错误处理：解决 ClassCastException

ClassCastException 应通过设计预防而非捕获处理，核心是转换前用 instanceof 或 Class.isInstance() 校验类型，结合泛型约束、框架配置明确（如 MyBatis resultType）、避免反射/多类加载器隐式风险，并通过日志和调试确认实际运行时类型。

ClassCastException 不该靠捕获来“处理”，而应通过设计预防。它不是业务异常，而是代码逻辑缺陷的信号——说明你试图把一个对象当成它根本不是的类型来用。

转换前必须做类型校验

强制转换（(TargetType) obj）永远不是第一选择。真正安全的做法是在转换前确认对象确实是目标类型：

• 用 instanceof 判断：适用于已知目标类的场景，比如 if (obj instanceof User)；注意它对 null 返回 false，天然防空指针
• 用 Class.isInstance()：适合动态类型，例如从配置读取类名后加载 clazz，再调用 clazz.isInstance(obj)，它支持 null
• 避免写 try-catch(ClassCastException) 来兜底——这会掩盖问题，让错误延迟暴露

泛型是编译期的第一道防线

原始集合（如 List、Map）是 ClassCastException 的高发区。泛型擦除虽发生在运行时，但编译器能提前拦截大部分非法操作：

• 声明时就明确类型：List<order> orders = new ArrayList();</order>，取值时无需强转，类型由编译器保障
• 避免 @SuppressWarnings("unchecked") 随意使用；每处都应有注释说明为何安全（比如确认上游已做过类型过滤）
• 对外部输入（JSON、数据库字段、HTTP 参数）不直接强转，优先用 Jackson 的 readValue(json, Target.class) 直接反序列化

警惕框架和反射带来的隐形风险

MyBatis、Spring、JSON 解析等框架返回的对象类型，常与预期不符：

• MyBatis 查询未指定 resultType 或 resultMap，默认返回 LinkedHashMap，若直接强转为 User 必崩
• 用反射调用方法后，别假设返回值一定是某类——先查 method.getReturnType() 或打印 result.getClass().getName()
• 多个模块加载同名类（如不同 jar 中的 com.example.User），即使类名相同，JVM 视为不同类型，互不可转

调试时快速定位真实类型

异常栈里那句 “X cannot be cast to Y” 是关键线索，但它只告诉你“想转什么”，没说“实际是什么”：

• 在转换语句前加日志：log.debug("obj type: {}, value: {}", obj.getClass(), obj)
• IDE 断点停在转换行，鼠标悬停或在变量视图中查看 obj 的实际 runtime class
• 检查 SQL 映射、DTO 构造、JSON 字段名拼写——很多报错表面是类型问题，根源其实是数据没映射对