Java数组协变允许子类数组赋值给父类数组引用（如String[]→Object[]），但运行时检查导致ArrayStoreException；泛型不变确保编译期类型安全，禁止List<String>与List<Object>互赋；协变通过通配符（如List<? extends Object>）显式、安全启用。

数组协变：为早期通用性妥协的运行时安全

Java 1.0 就支持数组协变，核心目标是让工具方法能“一招通吃”多种对象数组。比如 Arrays.toString(Object[]) 可直接接收 String[]、Integer[] 等任意对象数组，无需强制转型或重载。

这种设计依赖一个关键事实：只要子类能赋值给父类引用（String ≤ Object），那么对应数组类型也自动成立（String[] ≤ Object[]）。编译器允许 Object[] objArr = new String[3]，因为它只检查声明类型兼容性。

但代价是把类型检查推迟到运行时——JVM 每次执行 objArr[i] = x 都会核对 x.getClass() 是否属于数组底层真实组件类型（这里是 String）。一旦写入 new Integer(1)，立刻抛出 ArrayStoreException。

泛型不变：用编译期严格换全程类型可控

泛型出现在 Java 5，此时已有大量强类型需求。设计者明确拒绝数组式协变，根本原因就一条：不希望 List 被当作 List。

立即学习“Java免费学习笔记（深入）”；

所以 List 和 List 在类型系统里完全无关，既不是父子，也不可相互赋值。编译器在源头拦截所有越界操作：

java-enterprise

Java企业开发专家，专注于Spring Boot、微服务架构和JVM优化。适用于：Java语言掌握、

下载

• List list = new ArrayList();
• List → 编译失败
• list.add(new Date()); → 编译失败

这背后是泛型擦除机制：运行时所有 List 都退化为原始类型 List，类型安全全靠编译器静态分析撑住。

协变不是不要，而是交给更安全的表达方式

Java 并没放弃协变能力，只是把它从“默认开启”改为“显式启用”，通过通配符实现有约束的向上兼容：

• List extends Number> 可接收 List 或 List —— 协变读取安全
• List super Integer> 可接收 List 或 List —— 逆变写入安全
• PECS 原则（Producer-Extends, Consumer-Super）指导你何时该用哪种

这种方式把“谁可以读、谁可以写”的语义清晰暴露在类型签名里，不再靠隐式继承关系埋下隐患。

本质差异不在语法，而在类型生命周期管理

数组是具体化（reified）的：它在运行时完整保留组件类型信息，所以能做 ArrayStore 检查；

泛型是类型擦除（erased）的：它在运行时丢失所有泛型参数，只靠编译期约束保障安全。

一个靠运行时兜底，一个靠编译期封堵——这不是优劣之分，而是不同阶段对“安全”与“便利”权重的不同取舍。数组协变是 Java 早期向后兼容与简易性的选择；泛型不变则是成熟生态中对健壮性和可维护性的主动加码。