在泛型类中重写方法并保证类型安全的关键是让编译器能明确识别重写关系与类型约束：1.用具体类型继承泛型父类；2.方法签名中显式使用上界；3.避免依赖内部类作泛型参数；4.必要时用@SuppressWarnings+运行时校验。
1. 用具体类型继承泛型父类（最简单可靠）
让子类固定泛型参数，使所有方法签名在编译期完全确定：
- 父类定义为
abstract class Service<t> { void handle(T data) { ... } }</t> - 子类写成
class UserService extends Service<user> { @Override void handle(User data) { ... } }</user> - 此时
handle(User)和父类擦除后的handle(Object)能匹配，编译器自动生成桥接方法，类型安全由编译期保障
2. 在方法签名中显式使用上界（避免裸类型变量）
当必须保留泛型参数时，用 extends 约束类型范围，增强签名可识别性：
- 父类：
<t extends number> T add(T a, T b)</t> - 子类重写：
@Override <t extends integer> T add(T a, T b)</t>❌ 错误——不能缩小上界 - 正确做法是子类也声明相同上界：
@Override <t extends number> T add(T a, T b)</t>，或直接复用父类签名不加注解 - 重点：返回类型和参数类型必须与父类擦除后一致（即都变成
Number），否则视为重载而非重写
3. 避免依赖内部类作为泛型参数类型（常见陷阱）
如 M.Inner 这类写法在重写时极易失败，因为 M 是类型变量，M.Inner 在擦除后无法稳定映射到具体类：
- 错误示例：
void process(M.Inner req)→ 擦除为void process(Object req)，子类写void process(UserManager.Inner req)不被视为重写 - 解决方案：把内部类提升为独立泛型参数，例如
class Controller<m r> { void process(R req) { ... } }</m>，子类传入具体UserManager和UserRequest - 这样签名清晰，无擦除歧义，类型安全由泛型实参绑定保障
4. 必要时用 @SuppressWarnings("unchecked") + 显式类型校验
仅适用于无法改变接口设计的遗留场景（不推荐日常使用）：
立即学习“Java免费学习笔记（深入）”；
- 在重写方法内，用
if (!(arg instanceof ExpectedType)) throw new IllegalArgumentException(); - 再配合
@SuppressWarnings("unchecked")强制转型，把类型安全责任从编译期部分转移到运行期校验 - 注意：这放弃了泛型的核心优势，应作为最后手段，并配齐单元测试覆盖校验逻辑
