自动装箱与拆箱是编译期语法糖，非JVM运行时机制；编译器在赋值、传参、集合操作等类型不匹配处自动插入valueOf()或xxxValue()调用，本质是静态方法调用，故存在缓存陷阱、null拆箱NPE及==比较不确定性等问题。
Java中的自动装箱与自动拆箱发生在编译期，不是运行时由JVM动态处理的机制。
编译器插入方法调用，不是运行时“智能识别”
当你写 Integer i = 100; 或 int n = i; 时，javac 编译器会直接在字节码中生成对应的方法调用：
- 装箱 → 插入
Integer.valueOf(100) - 拆箱 → 插入
i.intValue()
用 javap -c 反编译就能看到明确的 invokestatic java/lang/Integer.valueOf 或 invokevirtual intValue 指令。这和你手写这些调用完全等价，只是省了几个字符。
缓存、NPE、性能表现都源于此设计
因为是编译期确定的调用，所以：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
-
Integer.valueOf(100)是否返回缓存对象，取决于其内部实现（如IntegerCache范围），但这是方法本身的逻辑，不是语言特性 -
null拆箱抛NullPointerException，是因为intValue()在运行时被调用，而该方法对null无防御——编译器不会加空检查 - 反复装箱可能创建大量对象，本质是反复调用
new Integer(...)（超出缓存范围时）
哪些场景会触发编译器插代码
只在类型契约不匹配、必须补全才能通过编译的地方才发生，典型包括：
- 赋值：基本类型 → 包装类，或包装类 → 基本类型
- 方法传参：实参类型与形参类型不一致（如传
int给Integer参数） - 集合操作：向
ArrayList<integer></integer>添加int，或从其中取值赋给int - 表达式运算与比较：如
Integer a + int b、a == 5、三元表达式统一类型
为什么不能理解为“隐式类型转换”
Java 规范中，int 和 Integer 是完全不同的类型，之间没有继承或子类型关系。所谓“自动”，只是编译器在必要位置静态补全了方法调用，不是类型系统层面的转换。这也解释了为何 == 比较行为不可靠——它比的是引用地址，而是否复用缓存对象，取决于 valueOf 的实现细节。
