instanceof用于多态场景下安全类型转换，需先检查非null对象是否属于某类型或其子类，避免ClassCastException；但不可替代判空、不支持动态类名、不保证逻辑正确性。
instanceof 用在多态场景下怎么避免 ClassCastException
多态时拿到一个父类或接口类型的引用，想调用子类特有方法，必须先确认实际类型——
就是干这个的，但它不是万能的类型“保险丝”，用错反而掩盖问题。
只对非
对象有效；
永远返回
，别指望它帮你判空
右边必须是编译期已知的类或接口名，不能是
或变量（Java 14+ 的模式匹配除外）
如果子类没重写父类方法，靠
分支调用仍可能逻辑错位——它只管“是不是”，不管“该不该”
示例：
instanceof 和 getClass() 的关键区别在哪
检查的是“是否属于某类型或其子类”，
拿到的是“运行时确切类对象”。多数人混淆这两者，结果在需要精确类型时用了
，或在允许继承时硬比
。
→
；
→
做权限校验、策略分发等需严格区分实现类时，用
更稳妥
在泛型擦除后仍可用（如
），但
拿不到泛型信息，无法判断
和
Java 14+ 模式匹配下 instanceof 怎么少写一次强转
以前写
，要手动强转；现在可以一步绑定变量，既简洁又避免重复计算类型检查。
语法是
，后面直接用
，编译器保证非
且类型安全
仅限于局部变量绑定，不支持字段、方法参数或嵌套表达式（如
是非法的）
注意作用域：
只在
块内可见；
分支里不可用
示例：
替代 instanceof 的更健壮方案有哪些
频繁出现大段
优先考虑多态：把行为提到接口/抽象类中，让子类自己实现，而不是外面一堆
用
模式解耦类型识别和操作逻辑，适合结构稳定、操作多变的场景
枚举 + 策略映射（如
）比硬编码
更易测试和替换，但要注意类加载器隔离问题
反射调用
或
属于动态场景，性能差且绕过编译检查，除非真需要运行时决定类型
真正麻烦的不是写对
，而是它出现的位置——如果它出现在核心业务流程里，大概率说明抽象没做好，或者边界没划清。
instanceofnullnull instanceof SomeClassfalseString.classinstanceofObject obj = getUnknownObject();
if (obj instanceof List) {
((List) obj).add("x"); // 安全
} else if (obj instanceof String) {
System.out.println(((String) obj).length()); // 安全
}instanceofgetClass()instanceofgetClass()new ArrayList() instanceof Listtruenew ArrayList().getClass() == List.classfalseobj.getClass() == SpecificHandler.classinstanceofobj instanceof ListgetClass()ListListif (obj instanceof String) { ((String)obj).length(); }if (obj instanceof String s)snull(obj instanceof String s) ? s.length() : 0sifelseif (obj instanceof Integer i && i > 0) {
System.out.println("positive int: " + i); // i 已自动强转并判空
}instanceof 分支，往往说明设计上可以优化。硬编码类型检查难维护、易漏、不利于扩展。if-else instanceofVisitorMap, Handler> instanceofisAssignableFromasSubclassinstanceof