强转前必须用 instanceof 明确判断类型，再在 if 块内安全强转；instanceof 对 null 安全、不抛异常、语义清晰；需显式强转才能访问子类成员；泛型擦除下仅能检查原始类型；推荐封装类型分支为策略方法；优先用多态或接口替代强转；结合日志与监控提升可追溯性。
多态调用中需要访问子类特有成员时，强转本身不是问题，关键在于让转换行为可预期、可控制。核心逻辑是：先确认运行时类型，再执行转换，绝不跳过校验。
强转前必须用 instanceof 明确判断
instanceof 是最轻量、最可靠的运行时类型守门员。它不抛异常、对 null 安全（返回 false），且语义清晰。
- 写法要分开：先 if (obj instanceof Target)，再在 if 块内安全强转，避免写成
if (((Target)obj).method() > 0)—— 这样一旦类型不符，直接抛 ClassCastException，instanceof 形同虚设 - 注意编译时限制：instanceof 判断通过后，仍需显式强转才能访问子类字段或方法，因为引用变量的编译时类型仍是父类
- 泛型擦除场景下，instanceof 只能检查原始类型（如
List），无法判断List<string></string>中的泛型参数，此时需靠业务标识或封装类补充类型信息
把类型分支逻辑收口到一处
多个地方重复写 if (x instanceof A) { ... } else if (x instanceof B) { ... } 容易遗漏、难维护。推荐封装为策略型方法：
- 定义统一入口方法，接收父类引用，内部完成 instanceof 分支与转换
- 每个分支只做一件事：转成对应子类，调用其专属方法，或返回封装结果
- 未覆盖的类型可统一抛自定义异常（如 UnknownSubtypeException）或返回 Optional.empty()，避免静默失败
优先用多态替代强转，减少转型需求
频繁强转往往意味着设计可以优化。多态的本质是“用统一接口表达不同行为”，而非“先猜类型再强转”。
- 把子类特有行为抽象为父类中的 abstract 方法或 default 方法，由子类各自实现，调用方无需知道具体类型
- 若某功能确实只属于部分子类，可提取为接口（如
HasReportFeature），让符合条件的子类实现，再用if (obj instanceof HasReportFeature)判断，比硬绑具体类名更灵活 - 集合操作尽量用泛型（
List<user></user>而非List），从源头消除取值后强转的必要
结合日志与监控提升可追溯性
即使加了 instanceof，实际运行中仍可能遇到意料之外的类型。这时强转逻辑是否留痕，决定了问题能否快速定位。
- 在 instanceof 为 false 的分支里记录 warn 日志，包含对象 getClass().getName()、hashCode 和上下文线索
- 对关键强转点添加指标埋点（如 “user_cast_failure_count”），便于观察异常分布趋势
- 测试时主动构造边界用例：传入新加入的子类、null、mock 对象，验证分支覆盖与错误响应是否合理
