java多态与泛型擦除叠加时类型安全的核心是分阶段管控：编译期用泛型边界（如list
Java 中多态与泛型擦除叠加时，类型转换安全问题的核心在于：编译期靠泛型约束、运行时靠多态行为，但擦除让二者无法天然对齐。真正安全的做法不是回避擦除，而是明确各阶段责任——编译期用泛型边界封住非法写入，运行时用多态接口+显式校验守住读取出口。
用上界通配符限定多态读取范围
当方法需接收多种子类型集合（如 List<integer></integer>、List<double></double>）并统一处理，不能直接声明 List<number></number>（它不接受子类列表），而应使用 List extends Number>：
- 编译期允许传入任意
Number子类的列表，满足多态兼容性 - 运行时所有元素可安全转为
Number，无需强制转换或instanceof - 禁止向该引用添加非
null元素，从源头避免破坏类型一致性
写操作场景改用具体类型+工厂模式
若需动态构造并填充泛型容器（例如根据配置创建 List<string></string> 或 List<localdatetime></localdatetime>），不能依赖运行时推断，而应显式传递类型凭证：
- 方法签名接收
Class<t></t>参数，如<t> List<t> createList(Class<t> elementType)</t></t></t> - 内部用该
Class对象做运行时类型检查（如element.getClass() == elementType）或反射构造 - 避免返回原始类型再强转，把类型责任前移到创建环节
运行时校验必须落在具体值上，而非容器声明
泛型擦除后，List 本身无法验证元素类型，但你可以控制元素访问路径：
- 封装一个带校验的包装类，如
SafeList<t></t>，在get(int)内部检查实际元素是否为T实例 - 对关键业务数据，在反序列化或外部输入入口处做一次性全量校验（如遍历
rawList，用instanceof验证每个元素） - 校验失败时抛出语义明确的异常（如
IllegalArgumentException("Expected String, got Integer")），而不是等后续ClassCastException模糊报错
避免桥接方法引发的隐式转换陷阱
当泛型类被继承并重写方法时，编译器生成的桥接方法可能掩盖类型不匹配：
- 例如
class IntBox extends Box<integer></integer>重写set(Integer)，桥接方法会生成set(Object) - 若父类
Box<t></t>的set方法未加final，外部可通过原始类型引用调用桥接方法，绕过泛型检查 - 解决方案：关键 setter/getter 声明为
final；或在重写方法中主动校验参数类型（if (!(obj instanceof T)) throw ...）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
