泛型继承不产生隐式强转，因类型擦除导致“假父子”关系；必须禁用原始类型、用TypeToken固化泛型、以组合替代泛型继承，并通过运行时校验保障类型安全。

泛型类继承本身不产生隐式强转，真正危险的是开发者误以为“继承关系 = 类型兼容”，从而跳过类型校验、盲目强转。这种认知偏差在生产环境常引发 ClassCastException，尤其在分层架构（如 DAO → Service → Controller）或泛型抽象基类被多处复用时尤为突出。

认清泛型继承的“假父子”本质

Java 中泛型是编译期特性，运行时已擦除。即使有 class Base {} 和 class UserRepo extends Base {}，JVM 里 UserRepo 的父类仍是原始类型 Base，不是 Base。这意味着：

• 不能靠 obj instanceof Base —— 语法错误，泛型不可用于 instanceof
• Base b1 = new UserRepo() 编译失败，但 Base b2 = new UserRepo() 合法，此时 b2 已丢失泛型信息
• 若某方法返回 Base（原始类型），下游代码写 (Base) result，看似合理，实则毫无保障——擦除后强转只校验原始类名，不校验泛型参数

封禁原始类型暴露路径

ClassCastException 往往从“泛型退化点”开始蔓延。必须阻断原始类型（raw type）向上游或跨模块泄露：

• 禁止 public 方法签名返回原始泛型类，例如避免 public Base getData()；应改为 public Base getData(Class type) 或明确具体子类 public UserRepo getUserRepo()
• DAO 层接口统一使用泛型方法：将 Object findById(Long id) 改为 T findById(Long id, Class targetType)，由调用方传入类型证据
• 构建工具层启用 -Xlint:unchecked 编译警告，并设为 error（Maven 中配置 -Xlint:unchecked），让原始类型使用无法通过 CI

用类型令牌（TypeToken）固化泛型意图

当必须绕过擦除（如反序列化、缓存读取），需主动携带泛型结构信息：

• Jackson 场景：不用 mapper.readValue(json, Base.class)，改用 mapper.readValue(json, new TypeReference>() {})
• 自定义泛型容器时，构造器接收 TypeReference 或 Class，并在内部保存，后续强转前先比对 targetType.isInstance(obj)
• 避免在抽象基类中定义 protected T data 并直接返回 getData()；应封装为 R getDataAs(Class expected)，内部做 expected.isInstance(data) 校验并抛友好异常

重构继承链，用组合替代泛型继承滥用

许多“泛型继承陷阱”源于设计过度抽象。例如：

坏模式：abstract class Repository { abstract T load(ID id); } → class OrderRepo extends Repository { ... } → 外部强转 (Repository) repo 导致崩溃

好做法：

• Repository 接口不带泛型：interface Repository { T load(Class type, ID id); }
• 具体实现类内聚类型逻辑：class OrderRepo implements Repository { public T load(Class type, ID id) { if (type == Order.class) return (T) fetchOrder(id); throw new IllegalArgumentException(); } }
• 彻底消除“继承即类型兼容”的错觉，把类型决策权交给运行时校验而非继承关系