泛型擦除是设计约束而非后门，禁止绕过编译检查注入异构变量；压测应聚焦反序列化兼容性、泛型方法分发、通配符边界等真实影响面。

不能也不该绕过编译期类型检查来向泛型集合注入异构变量——这不是“实战技巧”，而是主动制造运行时风险的行为。

泛型擦除不是后门，而是设计约束

Java泛型擦除的本质是：编译器在生成字节码前，把 List<string></string>、List<integer></integer> 全部抹平为原始类型 List，仅保留桥接逻辑和强制转换。它不提供“绕过检查”的能力，只意味着运行时无法区分二者。试图利用这点注入非法类型，等于放弃编译器为你设下的第一道安全护栏。

例如：

• 写 list.add("hello") 到声明为 List<integer></integer> 的变量上 —— 编译直接报错，根本过不了
• 用反射调用 list.getClass().getMethod("add", Object.class).invoke(list, "boom") —— 这确实能塞进去字符串，但后续调用 get(0) + 1 会立刻抛 ClassCastException
• 这种“成功注入”只是字节码层面的侥幸，不是可控能力，而是隐患埋点

压力测试需要的是可控异构数据，不是破坏类型契约

真实压测场景中，若需验证集合对混合类型的容错或边界行为，应通过合法、可追溯的方式构造输入：

• 使用原始类型集合：List rawList = new ArrayList()，明确放弃泛型约束，再混入 String、Integer、null 等
• 定义公共父类/接口容器：List<object></object> 或 List<serializable></serializable>，再放入不同子类型（仍保持类型安全）
• 借助 JSON 反序列化模拟脏数据：gson.fromJson(jsonWithMixedValues, List.class)，让外部输入自然触发类型模糊场景

真正该关注的擦除相关压测点

与其强行注入异构值，不如聚焦泛型擦除带来的真实影响面进行验证：

• 反序列化兼容性：测试 List<user></user> 和 List<order></order> 经 Jackson/Gson 序列化后是否因擦除导致类型丢失、反解失败
• 泛型方法多态调用：验证 <t extends number> void process(List<t>)</t></t> 在传入 List<integer></integer> 和 List<double></double> 时桥接方法是否正确分发
• 通配符边界行为：用 List super Integer> 接收 ArrayList<number></number> 并 add()，确认擦除后实际运行时类型兼容逻辑

泛型擦除是 Java 类型系统的一部分，不是漏洞。压测的价值在于暴露真实链路中的脆弱环节，而不是人为撕开类型安全的封条。用对方式，才能测出真问题。