Java泛型擦除不可绕过，因它是JVM设计机制而非漏洞；运行时无泛型信息，无法instanceof判断、getClass返回原始类型，反射需依赖声明位置；原始类型、Object转型等仅放弃编译检查，非真正绕过。
Java 中无法真正“绕过”泛型擦除来规避编译期类型检查——因为泛型擦除是 JVM 的设计机制，不是漏洞，而类型检查是编译器的保护机制。但开发者有时会误以为某些写法“绕过了检查”，其实是利用了擦除后的运行时行为或类型系统边界情况。下面说明几种常见误解和实际可操作的、与擦除相关的行为（注意：不推荐用于生产代码中的类型规避）：
泛型信息在运行时不存在，所以无法做运行时类型校验
Java 泛型是编译期特性，字节码中不保留泛型类型参数（如 List<String> 擦除为 List）。这意味着：
- 无法在运行时通过
instanceof判断泛型参数，例如list instanceof List<String>是语法错误 -
getClass()返回的是原始类型，new ArrayList<String>().getClass() == new ArrayList<Integer>().getClass()为 true - 反射获取泛型类型需依赖声明位置（如字段、方法签名），而非实例本身
用原始类型（raw type）抑制泛型检查
声明变量或参数时不带类型参数，使用原始类型，会关闭编译器对该处的泛型检查：
-
List rawList = new ArrayList<String>(); rawList.add(123);编译通过（但触发警告） - 后续若把
rawList强转为List<String>并遍历取值，会在运行时抛ClassCastException - 这是明确放弃类型安全，不是“绕过”，而是主动退回到 Java 5 之前的状态
借助 Object 和强制转换欺骗编译器
由于擦除后集合只认 Object，可通过中间转型绕过部分检查（危险且易出错）：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
立即学习“Java免费学习笔记（深入）”；
-
List<String> list = new ArrayList<>(); List raw = list; raw.add(new Integer(42));—— 编译无错，运行时报错 - 类似地，用
Method.invoke()或反射调用泛型方法时，编译器不校验实参类型，全靠运行时承担风险 - 这种写法不会让编译器“失效”，只是跳过了它能检查的那一层；本质是把类型责任推给开发者和运行时
类型令牌（TypeToken）等技巧不能恢复擦除，只是记录类型意图
像 Gson、Jackson 中的 TypeToken<List<User>>() {} 写法，利用匿名子类的继承关系，在运行时通过反射读取父类的泛型签名。但这：
- 仅适用于**编译期已知、且被固化在类字节码中**的泛型（如匿名类、字段声明）
- 对局部变量、泛型方法形参、普通泛型实例无效
- 不是“绕过擦除”，而是提前把类型信息“藏进类结构”，属于补救策略，非通用绕过手段
不复杂但容易忽略：泛型擦除不是缺陷，是兼容性和实现简洁性的权衡。真要动态类型行为，应考虑用 Class<?> 显式传递类型，或改用其他语言特性（如 record + sealed class 配合模式匹配），而不是试图对抗编译器。
