泛型继承不产生隐式强转，因类型擦除导致“假父子”关系；必须禁用原始类型、用TypeToken固化泛型、以组合替代泛型继承，并通过运行时校验保障类型安全。
泛型类继承本身不产生隐式强转，真正危险的是开发者误以为“继承关系 = 类型兼容”，从而跳过类型校验、盲目强转。这种认知偏差在生产环境常引发 ClassCastException，尤其在分层架构（如 DAO → Service → Controller）或泛型抽象基类被多处复用时尤为突出。
认清泛型继承的“假父子”本质
Java 中泛型是编译期特性，运行时已擦除。即使有 class Base<t> {}</t> 和 class UserRepo extends Base<user> {}</user>，JVM 里 UserRepo 的父类仍是原始类型 Base，不是 Base<user></user>。这意味着：
- 不能靠
obj instanceof Base<user></user>—— 语法错误，泛型不可用于 instanceof -
Base<string> b1 = new UserRepo()</string>编译失败，但Base b2 = new UserRepo()合法，此时b2已丢失泛型信息 - 若某方法返回
Base（原始类型），下游代码写(Base<user>) result</user>，看似合理，实则毫无保障——擦除后强转只校验原始类名，不校验泛型参数
封禁原始类型暴露路径
ClassCastException 往往从“泛型退化点”开始蔓延。必须阻断原始类型（raw type）向上游或跨模块泄露：
- 禁止 public 方法签名返回原始泛型类，例如避免
public Base getData()；应改为public <t> Base<t> getData(Class<t> type)</t></t></t>或明确具体子类public UserRepo getUserRepo() - DAO 层接口统一使用泛型方法：将
Object findById(Long id)改为<t> T findById(Long id, Class<t> targetType)</t></t>，由调用方传入类型证据 - 构建工具层启用 -Xlint:unchecked 编译警告，并设为 error（Maven 中配置
<compilerargs><arg>-Xlint:unchecked</arg></compilerargs>），让原始类型使用无法通过 CI
用类型令牌（TypeToken）固化泛型意图
当必须绕过擦除（如反序列化、缓存读取），需主动携带泛型结构信息：
- Jackson 场景：不用
mapper.readValue(json, Base.class)，改用mapper.readValue(json, new TypeReference<base>>() {}) - 自定义泛型容器时，构造器接收
TypeReference<t></t>或Class<t></t>，并在内部保存，后续强转前先比对targetType.isInstance(obj) - 避免在抽象基类中定义
protected T data并直接返回getData()；应封装为<r> R getDataAs(Class<r> expected)</r></r>，内部做expected.isInstance(data)校验并抛友好异常
重构继承链，用组合替代泛型继承滥用
许多“泛型继承陷阱”源于设计过度抽象。例如：
坏模式：abstract class Repository<t> { abstract T load(ID id); }</t> → class OrderRepo extends Repository<order> { ... }</order> → 外部强转 (Repository<user>) repo</user> 导致崩溃
好做法：
- Repository 接口不带泛型：
interface Repository { <t> T load(Class<t> type, ID id); }</t></t> - 具体实现类内聚类型逻辑：
class OrderRepo implements Repository { public <t> T load(Class<t> type, ID id) { if (type == Order.class) return (T) fetchOrder(id); throw new IllegalArgumentException(); } }</t></t> - 彻底消除“继承即类型兼容”的错觉，把类型决策权交给运行时校验而非继承关系
