arraystoreexception是jvm在数组写入时依据其实际组件类型进行运行时校验失败所致，根本原因在于数组协变性与运行时类型检查机制，泛型擦除仅加剧了类型不安全的隐蔽性。
ArrayStoreException 不是因为泛型擦除“直接导致”的，而是泛型擦除 + 数组协变 + 运行时类型检查三者共同作用下的必然结果。它的触发点始终在数组写入瞬间（aastore 字节码指令），由 JVM 根据数组**实际创建时的组件类型**做校验，与泛型声明无关。
真实触发机制：数组底层类型说了算
Java 数组在堆上创建时就固化了组件类型（component type），这个信息保存在数组对象头中，运行时可被 JVM 访问。无论你用什么引用类型指向它（Object[]、Number[] 或 String[]），JVM 写入时只认这个真实类型。
-
例子：
Object[] arr = new String[5];—— 数组真实类型是String[] - 执行
arr[0] = "ok";✔️ 成功（String是String的子类） - 执行
arr[0] = 123;❌ 抛ArrayStoreException（Integer不是String的子类）
泛型擦除在这里起什么作用？
泛型擦除本身不产生异常，但它让开发者更容易写出“看起来安全、实则危险”的代码：
- 声明
List<string> list = new ArrayList();</string>→ 编译后变成List list，但add()方法仍受编译器约束 - 错误做法：
T[] elements = (T[]) new Object[10];→ 擦除后等价于Object[]，但外部可能把它当作String[]使用 - 一旦把该数组暴露出去（比如提供
elements字段或返回原始数组），调用方往里塞Integer，而 JVM 检查发现底层其实是Object[]（允许任何引用类型），就不会报错；但如果这个数组实际是new String[10]强转而来，JVM 就按String[]校验，立刻失败
为什么泛型数组禁止创建？
因为 new T[10] 在擦除后变成 new Object[10]，但语义上它应该像 String[] 一样具备运行时类型约束。JVM 无法在运行时知道你本意要的是 String[] 还是 Integer[]，所以干脆编译期就禁止，避免留下隐患。
- 合法：
String[] arr = new String[5];→ 组件类型明确为String - 非法：
List<string>[] arr = new List<string>[5];</string></string>→ 编译失败 - 绕过写法：
List<string>[] arr = (List<string>[]) new List[5];</string></string>→ 编译通过，但运行时若误存List<integer></integer>，就会触发ArrayStoreException
关键结论：不是“泛型出问题”，而是“数组太诚实”
JVM 对数组的类型检查是严格且即时的，它不看变量声明类型，只看数组对象创建时的真实组件类型。泛型擦除削弱了编译期防护，放大了这种运行时检查的暴露面——尤其当泛型逻辑和数组操作混用时，表面类型安全，底层却已埋雷。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
