Java泛型不允许List，根本原因是类型擦除要求泛型参数必须可擦除为引用类型（如Object或其子类），而int是JVM基本类型，不继承Object、无运行时类对象，无法满足擦除规则；编译器在语法分析阶段即报“Type argument cannot be of primitive type”错误。
Java 不允许 List 这类写法，根本原因不是语法懒、不是编译器故意卡你，而是类型擦除机制与 JVM 类型系统之间存在硬性冲突——int 无法被擦除为 Object，而泛型的底层实现又强依赖这个擦除目标。
为什么 List 编译直接报错？
错误信息是明确的：Type argument cannot be of primitive type。这不是警告，是编译器在词法/语法分析阶段就拦截的硬限制。
- 泛型类型参数必须是“可擦除为引用类型”的东西，而
int是 JVM 基本类型，不继承Object，没有运行时类对象（int.class存在，但int.class instanceof Class>是 true，它仍不是引用类型） - 擦除规则要求：无界泛型参数（如
T）必须能被替换为Object；有界参数（如T extends Number）则擦除为上界。但int既不能当Object，也不能当Number的实例（它是值，不是对象） - 即使你只声明不使用，比如
class Holder+{ } Holder，也会在解析尖括号时失败，不进语义分析阶段h;
Integer 替代 int 的代价在哪？
用 List 能过编译，但不是“等价替代”，而是绕过矛盾的妥协方案，伴随三类实际风险：
-
空指针风险：
list.get(0) + 1在元素为null时触发NullPointerException，拆箱自动调用intValue()，而该方法对null无防御 -
缓存陷阱：
Integer a = 127, b = 127;→a == b为true；但Integer c = 128, d = 128;→c == d为false。用==比较包装类数值，结果不可靠 - 装箱开销真实存在
- 循环中
list.add(i)（i是int）会反复创建Integer对象；大数据量下 GC 压力和内存占用明显上升
类型擦除如何放大基本类型的缺失？
擦除不只是“去掉尖括号”，它让泛型类在运行时彻底丢失类型参数能力，而这套机制从设计上就排除了基本类型参与的可能：
-
new T[10]非法 → 因为擦除后 JVM 不知道T是什么，更别说分配int[]还是Integer[]；而ArrayList内部用的是Object[]，再靠强转访问，这本身就要求元素必须是引用类型 -
if (obj instanceof T)编译失败 → 擦除后T不存在，JVM 只认原始类型；但即使支持，int也无法参与instanceof（它不是类） -
Class不合法 →clazz = T.class T.class在擦除后无意义，且int.class是Class吗？不是，它是Class，和泛型期望的引用类型 Class 对象不兼容
真正容易被忽略的点是：这不是一个“未来可能优化”的问题，而是 JVM 类型模型和泛型擦除机制共同锁定的设计边界。所有试图绕过它的方案（如自定义字节码、反射构造原生数组）都会破坏类型安全或脱离标准 Java 语义。高频数值场景下，别硬扛 List，直接换 TIntArrayList（Trove）或 IntList（Eclipse Collections）这类原生集合库——它们不走泛型路径，从源头避开擦除与基本类型的矛盾。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
