自动装箱和拆箱发生在编译期，是语法糖处理阶段由编译器插入Integer.valueOf()、intValue()等调用；泛型擦除与之独立但协同，擦除前已根据静态类型完成装箱/拆箱，字节码中体现为明确方法调用。
Java 的自动装箱（autoboxing）和拆箱（unboxing）在泛型中看似“隐式执行”，其实并非在类型擦除后才发生，而是发生在编译期（擦除前）的语法糖处理阶段，并由编译器插入必要的转换代码；运行时泛型已擦除，但装箱/拆箱操作早已固化为字节码中的明确方法调用（如 Integer.valueOf()、intValue()）。
自动装箱/拆箱发生在编译期，不是运行时“感知泛型”
泛型擦除是 Java 编译器在生成字节码前完成的：所有类型参数（如 List<Integer>）被替换为原始类型（List），同时编译器根据上下文插入强制类型转换（cast）和装箱/拆箱调用。
- 你写
list.add(42)（list是List<Integer>），编译器自动转成list.add(Integer.valueOf(42)) - 你写
int x = list.get(0)，编译器自动转成int x = list.get(0).intValue() - 这些转换在擦除后依然存在——因为它们已是字节码的一部分，与泛型信息无关
擦除后仍能安全装箱/拆箱，靠的是“目标类型推断”+显式插入
编译器不依赖运行时泛型类型，而是依据变量声明、方法签名、赋值左侧类型等静态信息决定是否需要装箱或拆箱。
- 例如：
Integer i = 100;→ 编译器看到左侧是Integer，右侧是int字面量，插入Integer.valueOf(100) -
ArrayList<Integer> list = new ArrayList<>(); list.add(5);→ 编译器知道add(E)的形参类型是Integer（擦除前），所以对5装箱 - 即使擦除后
add在字节码中签名是add(Object)，但装箱动作已在调用前完成
注意：擦除后无法恢复泛型类型，但装箱逻辑已固化
运行时 ArrayList 确实只存 Object，但它存的是已经装箱好的 Integer 实例；取出来时，编译器插入的 intValue() 调用会作用于实际对象——只要运行时对象确实是 Integer，就不会出错。
立即学习“Java免费学习笔记（深入）”；
- 危险情况：
list.add(new Object())（绕过泛型检查）再尝试int x = list.get(0)→ 编译期允许（因擦除后是Object），但运行时抛ClassCastException（因Object没有intValue()） - 这说明：装箱/拆箱的安全性依赖编译期类型检查，而非运行时泛型；擦除不破坏转换，但也不提供额外保护
反编译验证：装箱/拆箱是真实字节码指令
用 javap -c 查看编译后的字节码，能看到明确的 invokestatic java/lang/Integer.valueOf 和 invokevirtual java/lang/Integer.intValue，证明它们不是“运行时魔法”，而是编译器写死的操作。
- 泛型擦除和自动装箱是两个独立但协同的编译阶段：先做类型检查和装箱插入，再做类型擦除和桥接方法生成
- 没有“擦除后动态判断要不要装箱”——那不可能，因为运行时根本没有
<Integer>这个信息
