instanceof 必须在转型前使用，否则可能抛出 ClassCastException；它对 null 返回 false，但泛型擦除使其无法检查参数化类型，接口检查需关注实际运行时实现而非源码声明。
instanceof 检查必须在转型前做，否则可能抛 ClassCastException
转型（cast）本身不检查类型安全性，JVM 只在运行时真正用到该引用时才校验。如果跳过 instanceof 直接强转，一旦对象不是目标类型，就会在执行到那行时崩出 ClassCastException——这个异常无法靠编译器提前发现。
实操建议：
- 所有非泛型容器（比如
List、Object[]）里取出来的元素，在转型前都应先用instanceof判断 - 不要依赖“我确定它就是这个类型”这种假设，尤其当数据来自外部输入、反射或旧代码时
-
instanceof对null返回false，所以无需额外判空；但若你后续逻辑依赖非空，仍需单独处理
注意泛型擦除后 instanceof 不能检查泛型参数
Java 泛型在编译后被擦除，instanceof 只能检查原始类型，不能检查带泛型的类型字面量。比如 list instanceof ArrayList<string></string> 是非法语法，编译不过。
实操建议：
- 只能写
list instanceof ArrayList，不能加<string></string> - 若需确认泛型内容，得靠遍历 + 元素级
instanceof，例如：先确认是ArrayList，再对第一个元素做item instanceof String - 使用
Class.isInstance()也受同样限制，它和instanceof行为一致，只是动态版
接口类型检查要小心实现类未显式声明的情况
instanceof 对接口有效，但前提是运行时对象实际实现了该接口。有些类通过代理、ASM 或序列化框架生成，可能没在源码里写 implements X，但运行时确实支持——这时 instanceof 仍会返回 true；反之，若仅继承了某个实现类却未重写关键方法，也可能被误认为符合接口语义，但这是设计问题，不是 instanceof 的锅。
实操建议：
- 检查接口时，确保你关心的是“能否调用某组方法”，而不是“源码是否写了 implements”
- 避免用
instanceof替代业务逻辑判断，比如“是不是管理员”不该靠user instanceof AdminUser，而应查角色字段 - 对接口检查后仍需考虑方法是否真可安全调用（比如某些实现可能抛
UnsupportedOperationException）
替代方案：Optional + 方法引用比裸 instanceof 更健壮
硬写 if (obj instanceof String) { s = (String) obj; } 容易漏掉分支、重复 cast、或者把逻辑散落在多处。现代写法更倾向封装行为而非类型。
实操建议：
- 用
Optional.ofNullable(obj).filter(String.class::isInstance).map(String.class::cast)把检查+转型+空处理链在一起 - 对常见转换场景（如转数字），优先用工具方法：
NumberUtils.toInt(str, 0)比if (s instanceof String) Integer.parseInt((String)s)更安全 - 如果转型后只调一个方法，直接用
MethodHandle或反射 +try/catch可能比反复检查更轻量，但要权衡可读性
instanceof 返回 true，也不能保证转型后的对象处于可用状态——比如反序列化失败的对象，类型对了，字段却是 null。 
