java泛型擦除是编译期主动移除类型参数的设计选择，无界类型擦除为object、有界类型擦除为上界（如number），并自动插入强制转换；运行时仅存原始类型，导致instanceof、new t()等不可用，且list与list的getclass()结果相同。
Java 泛型的“擦除”不是丢失，而是编译期主动移除——泛型类型参数在字节码里根本不存在，JVM 运行时看到的只有原始类型（如 List、Map）或边界类型（如 Number）。它本质是 Java 为兼容 JDK 5 之前代码做的妥协设计，所有类型安全都靠编译器“提前检查 + 自动插转换”来兜底。
泛型擦除是怎么发生的
编译器执行三步操作：
- 把无边界的类型参数（如
<t></t>）统一替换成Object - 把有上界的类型参数（如
<t extends number></t>）替换成上界类型（Number） - 在调用处自动插入强制类型转换，比如
list.get(0)编译后变成(String) list.get(0)
运行时类型信息为什么拿不到
因为擦除后，不同泛型实例在 JVM 中是同一个 Class：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
new ArrayList<string>()</string>和new ArrayList<integer>()</integer>的.getClass()完全相等 -
list instanceof List<string></string>是语法错误——JVM 不认识带泛型的类型写法 - 通过反射调用
Field.getGenericType()可能拿到ParameterizedType，但仅限于**泛型被显式保留在字节码签名中**的场景（如字段声明为List<string> names</string>），而对象实例本身不携带该信息
这些限制会带来什么实际问题
常见踩坑点直接对应擦除机制：
- 不能创建泛型数组：
new T[10]编译报错，因为T在运行时是未知的 - 静态上下文不能用类型参数：
static T value不合法，静态变量属于类而非实例，而擦除后所有泛型实例共享同一份字节码 - 方法重载冲突：
void handle(List<string>)</string>和void handle(List<integer>)</integer>编译不过，擦除后都是handle(List)，签名重复 - 运行时类型转换风险：若绕过编译检查（如强制转型），
(List<integer>) stringList</integer>能通过编译，但取值时抛ClassCastException
想在运行时“找回”类型怎么办
擦除不可逆，但可通过编码技巧间接保留部分信息：
- 用
TypeReference（Jackson）或new ArrayList<string>() {{}}.getClass().getGenericSuperclass()</string>解析父类泛型签名 - 泛型类构造时传入
Class<t></t>实参，如new Box<string>(String.class)</string>，把类型信息存为字段 - 避免依赖运行时泛型判断逻辑，改用接口抽象或运行时类型标记（如字段加
@JsonTypeInfo）
不复杂但容易忽略：擦除不是 bug，是设计选择；理解它，才能避开那些看似合理却编译失败、或运行时报错的陷阱。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
