int与integer间无真正隐式转换，实为编译器插入的自动装箱（如integer.valueof()）和拆箱（如intvalue()）语法糖，仅发生在赋值、传参、集合添加等明确场景，不改变类型系统本质。
int 与 Integer 之间的“隐式类型转换”其实不是传统意义上的隐式类型转换，而是编译期插入的语法糖——自动装箱（autoboxing）和自动拆箱（unboxing）。它不改变 Java 类型系统的基本规则，也不属于基本类型间的大小兼容转换（比如 int → long 那种），而是一种由编译器主动补全方法调用的机制。
这不是真正的隐式类型转换
Java 中真正的隐式类型转换只发生在**基本类型之间**，且必须满足“小范围→大范围、无精度损失”的条件，例如：
- byte → short → int → long → float → double
- char → int（因为 char 是无符号16位整数，可安全转为 int）
但 int 和 Integer 分属不同范畴：一个是基本类型，一个是引用类型。它们之间不存在继承或包含关系，JVM 不允许直接把基本类型当作对象使用。所以所谓“隐式转换”，本质是编译器在你写 Integer i = 100; 或 list.add(42); 这类代码时，悄悄替你补上了 Integer.valueOf(100) 调用。
装箱发生在哪些明确场景
只有当语义上需要“把基本值当作对象用”时，编译器才触发自动装箱：
- 赋值给包装类变量：Integer x = 5;
- 作为参数传给期望包装类的方法：method(Integer arg)
- 添加到泛型集合：list.add(123) → 实际调用 list.add(Integer.valueOf(123))
- 三元表达式中类型统一：boolean b = true; Object o = b ? 1 : "a"; → 1 会被装箱为 Integer
注意：new Integer(5) 不触发装箱，它是显式构造，且已废弃；Integer i = (Integer) 5; 会编译失败，因为强制转型不能跨基本/引用类型。
拆箱也是编译期决定的
当你把 Integer 当作基本类型来用，比如参与算术运算、比较、赋值给基本类型变量时，编译器会在对应位置插入 intValue() 等方法调用：
- int j = i + 1; → 编译为 int j = i.intValue() + 1;
- if (i == 5) → 先拆箱再用 == 比较数值（若 i 为 null，则运行时报 NullPointerException）
- return i; // 方法返回 int，而 i 是 Integer → 自动调用 intValue()
这个过程完全由编译器静态分析决定，不依赖运行时类型推断，也没有反射或动态代理参与。
关键提醒：别被“隐式”二字误导
这种机制看似方便，但容易掩盖真实行为：
- == 比较两个 Integer 可能因缓存策略（-128~127）返回 true 或 false，实际比的是引用，不是值
- null 拆箱必崩，常见于数据库查出 null 后直接赋给 int
- 高频装箱（如循环中 list.add(i)）会创建大量临时对象，影响 GC 性能
- 泛型擦除后，List
存的全是对象，无法像数组 int[] 那样紧凑存储
理解这一点，就能明白：所谓“隐式”，只是写法省事；背后每一步都是确定的、可追溯的方法调用，不是魔法。
