instanceof 不足以防止 ClassCastException，它仅防范向下转型的显式强制转换，对泛型擦除、数组协变、反射调用等场景无效；需结合模式匹配、isInstance()、流式处理及类型安全API综合防护。
ClassCastException 发生时，instanceof 真的够用吗？
不够。它只防「向下转型」时的显式强制转换，对泛型擦除、数组协变、反射调用等场景完全不设防。
典型错误现象：ClassCastException 在 list.get(0) 或 (String)obj 处抛出，但前面明明写了 if (obj instanceof String) —— 问题往往出在泛型丢失或运行时类型已不是你认为的那个。
-
instanceof检查的是对象**实际运行时类型**，不是声明类型，也不是泛型参数类型 - 对原始类型（如
int）或null使用instanceof会编译报错或恒为false - 数组类型检查要写全，比如
obj instanceof String[]，不能只写String
泛型集合取值时怎么避免 ClassCastException
泛型在编译后被擦除，JVM 不知道 List<Integer> 和 List<String> 的区别。所以 list.get(0) 返回 Object，强转风险极高。
- 优先用增强 for 循环或 stream + 类型安全方法，让编译器帮你卡住：比如
list.stream().map(Integer::parseInt).toList() - 如果必须强转，先确认元素真实类型：
if (obj instanceof Integer i)（Java 14+ 模式匹配语法，比传统instanceof+ 强转更安全） - 避免裸写
(Integer) list.get(0)—— 这种写法跳过了任何运行时类型校验，一旦存入了别的类型，立刻崩
用 Class.isInstance() 替代 instanceof 的三种必要场景
当类型信息来自变量、配置或反射结果时，instanceof 语法无法使用，必须换方法。
立即学习“Java免费学习笔记（深入）”；
- 动态判断某个类加载器加载的类实例：
targetClass.isInstance(obj)，比obj.getClass() == targetClass更准（支持子类） - 处理
ClassLoader.defineClass()后生成的类，其类型与当前类路径下同名类不等价，==或instanceof都失效 - 框架中做插件隔离（如 OSGi、Spring Boot DevTools），同一类名可能对应多个 Class 实例，只能靠
isInstance()
数组和接口转型最容易踩的坑
数组是协变的，但这种协变不安全；接口实现类多态时，instanceof 虽然能过，但后续方法调用仍可能失败。
-
Object[] arr = new String[1]; arr[0] = new Integer(1);编译通过，运行时抛ArrayStoreException，不是ClassCastException—— 但根源相同：类型系统失守 - 接口转型如
if (obj instanceof Runnable)成立，不代表((Runnable)obj).run()一定不抛异常（比如实现类里手动 throw new UnsupportedOperationException） - 用
Arrays.asList()包装基本类型数组（如int[]）会把整个数组当一个元素，取出来强转成Integer必崩 —— 正确做法是用IntStream.of(arr).boxed().toList()
最常被忽略的一点：instanceof 只管「是不是这个类或其子类」，不管「有没有这个方法」「字段是否存在」「序列化版本是否兼容」。真要保安全，得结合白名单校验、sealed class、模块化封装，或者直接用 record + pattern matching 做结构约束。
