ClassCastException发生时instanceof不能直接用，因其对null返回false且无法校验泛型类型；须先判空再用instanceof，泛型校验需反射或协议，数组、包装类、代理对象等场景仍可能抛异常。
ClassCastException 发生时，instanceof 为什么不能直接用？
因为 instanceof 对 null 返回 false，但很多开发者在判空前就直接强转，导致异常仍会抛出。更隐蔽的是：泛型擦除后，instanceof 无法校验带泛型的类型（比如 List<string></string>），编译器只认 List，此时加 instanceof 看似安全，实际掩盖了运行时类型不匹配的风险。
常见错误现象：
— 方法接收 Object 参数，未判空就写 ((MyType) obj).doSomething()
— 用 instanceof List<string></string> 编译失败，退而用 instanceof List，结果后续取元素时抛 ClassCastException
- 必须先检查
obj != null，再用instanceof - 泛型类型校验要靠运行时反射（如
obj.getClass().getTypeName()）或约定协议，instanceof无能为力 - 若对象来自外部输入（如 JSON 反序列化、RPC 响应），类型不确定性高，
instanceof只是第一道过滤，不是银弹
用 instanceof 做安全转换的最小可靠模式
这不是语法糖，而是明确分离“判断”和“转换”两步，避免重复计算、逻辑耦合。Java 14+ 支持模式匹配（if (obj instanceof MyType mt)），但老版本必须手动拆开。
使用场景：工具类中封装通用转换逻辑、框架回调参数解析、DTO 转 VO 等明确需要类型兜底的地方。
立即学习“Java免费学习笔记（深入）”；
- 写法必须是：
if (obj != null && obj instanceof MyType) { MyType t = (MyType) obj; ... } - 禁止把强转写在
instanceof同一行右边（如obj instanceof MyType ? ((MyType)obj).x : null），这会让 IDE 和静态分析工具误判空安全性 - 如果后续要多次使用转换后的引用，务必提取为局部变量，而不是反复强转——既影响可读性，也存在并发下对象被修改导致类型不一致的极小风险
Class.isInstance() 和 instanceof 选哪个？
二者语义一致，但适用场景不同：instanceof 是编译期关键字，类型必须已知；Class.isInstance() 是运行时方法，适合类型由字符串、配置或上层传入的场景。
性能差异微乎其微（HotSpot 已优化），但兼容性要注意：Android API 26+ 才完全支持 isInstance() 在某些泛型边界下的行为。
- 硬编码类型 → 用
instanceof，更直观、IDE 支持好 - 类型来自
Class.forName("xxx")或 Spring 的ResolvableType→ 必须用clazz.isInstance(obj) - 不要用
obj.getClass() == Xxx.class替代 —— 子类实例会失败，而instanceof和isInstance()都支持继承关系
为什么加了 instanceof 还抛 ClassCastException？
最常被忽略的点：数组类型、原始类型包装类、代理对象。它们看起来像某个类型，但 JVM 类型系统不认为可直接强转。
典型例子：
— Object[] arr = new String[2];，然后 if (arr instanceof String[]) {...} 成立，但 (String[]) arr 在运行时可能仍失败（如果 arr 实际是 Object[]）
— Integer i = 128; Long l = i.longValue();，试图 (Long) i 一定失败，尽管都是数字包装类
— Spring AOP 代理对象，instanceof 接口返回 true，但强转成具体实现类会失败
- 数组类型校验后，建议用
Array.get()+ 显式转型，而非整体强转 - 数值类型之间不互转，用
Number的xxxValue()方法，别依赖instanceof - 面对代理对象，优先面向接口编程；若必须访问实现类字段，用
Advised接口或AopProxyUtils.ultimateTargetClass()
instanceof 就自动消失。校验只是起点，真正关键的是清楚你校验的对象，在 JVM 里到底是什么东西。 
