instanceof 安全强转的核心是“该不该转、转完怎么用”，需结合数据结构逻辑；优先用接口判断行为，必要时覆盖子类检查；Java 14+ 推荐模式匹配避免重复强转；慎防代理类陷阱，宜用接口或反射；分支过多时应改用策略模式。
在多态调用中，用 instanceof 安全强转，核心不是“能不能转”，而是“该不该转、转完怎么用”。它本质是运行时类型守门人，必须配合清晰的数据结构逻辑（比如继承层级、接口契约、业务语义）才能真正安全。
明确数据结构中的类型关系再判断
多态对象的类型信息藏在继承链或实现关系里。盲目写 obj instanceof SomeClass 很容易漏掉子类变体或误判接口实现。
- 若业务只关心行为（如“能保存”），优先定义接口（
Savable），用obj instanceof Savable+ 接口方法调用，不依赖具体类 - 若必须区分具体实现（如“是 MySQL 还是 Redis 存储”），检查时要覆盖常见子类：
obj instanceof MySQLStorage || obj instanceof RedisStorage - 避免只查父类就断定可用：例如
obj instanceof Collection为 true，不代表((Collection)obj).add()一定成功（Arrays.asList()返回的是不可添加的集合）
用模式匹配替代重复强转（Java 14+）
老写法易出错：先 instanceof，再手动强转，变量作用域分散，还可能漏掉 null 判断（虽然 instanceof 本身对 null 安全，但后续逻辑未必）。
- 推荐写法：
if (obj instanceof String s && !s.isBlank()) { System.out.println(s.length()); }——s已自动非空、已绑定类型，直接用 - 支持条件连写：
if (obj instanceof Integer i && i > 0)，把类型检查和业务逻辑合并，更紧凑 - 注意：
s只在if块内有效；不能用于三元表达式或字段赋值
避开代理类陷阱（Spring/AOP 场景）
在 Spring 等框架中，service bean 往往被 CGLIB 或 JDK 动态代理增强。此时 obj instanceof UserServiceImpl 仍返回 true，但强转会失败。
- 根本原因：代理类继承自
UserServiceImpl，满足instanceof，但不是原始类本身 - 安全做法：改用接口编程，让
UserServiceImpl实现UserService，然后判断obj instanceof UserService - 若必须用具体类逻辑，改用反射方式：
UserServiceImpl.class.isInstance(obj)，它语义一致，但更灵活（可配置、可 mock）
结合策略模式减少硬编码分支
当 instanceof 分支越来越多（比如处理 5 种不同消息类型），代码会变得臃肿难维护。这时应把类型判断逻辑外移。
- 定义策略接口：
MessageHandler<T>，每个子类对应一个实现（EmailHandler、SmsHandler） - 用
Map<Class<?>, MessageHandler>注册处理器，运行时通过handlerMap.get(obj.getClass())获取，避免 if-else 链 - 如果必须保留 instanceof（如泛型擦除后需判断原始类型），可封装成工具方法：
isType(obj, List.class)，内部调用List.class.isInstance(obj)
