自动装箱和拆箱是编译期语法糖，非JVM运行时机制；装箱发生在赋值、传参、入集合时插入valueOf()，拆箱发生在运算、条件判断时插入xxxValue()；需警惕null拆箱NPE及==比较的缓存陷阱。
自动装箱和拆箱是 Java 编译器在基本类型和对应包装类之间自动插入的隐式转换，不是 JVM 运行时的“魔法”，而是编译期生成的语法糖。
什么时候发生自动装箱
当把基本类型值赋给包装类型变量、传给期望包装类型的参数、或放入泛型集合时，编译器会插入 Integer.valueOf()、Boolean.valueOf() 等调用：
-
Integer i = 100;→ 实际编译为Integer i = Integer.valueOf(100); -
list.add(42);（list是ArrayList）→ 插入Integer.valueOf(42) -
public void foo(Boolean b) { }调用foo(true)→ 插入Boolean.valueOf(true)
注意：valueOf() 方法内部有缓存机制（如 Integer 缓存 -128 到 127），所以 Integer a = 100; Integer b = 100; 时 a == b 为 true，但 Integer c = 200; Integer d = 200; 时 c == d 很可能为 false —— 这是常见坑点。
什么时候发生自动拆箱
当把包装类型变量用于需要基本类型的地方，编译器会插入 .intValue()、.booleanValue() 等调用：
-
int x = new Integer(42);→ 编译为int x = new Integer(42).intValue(); -
if (boolObj)（boolObj是Boolean）→ 插入boolObj.booleanValue() -
int sum = i1 + i2;（i1、i2是Integer）→ 先拆箱再算术加法
危险点：若包装类引用为 null，拆箱会直接抛出 NullPointerException，例如 Integer i = null; int x = i; 运行时报错，而非编译错误。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
为什么不能在 == 比较中混用包装类和基本类型
== 对基本类型比较值，对引用类型比较地址。当一边是包装类、一边是基本类型时，Java 会先拆箱再比较值 —— 表面安全，实则隐藏风险：
-
Integer a = 100; boolean b = a == 100;→ 安全，a拆箱后比较 -
Integer a = null; boolean b = a == 0;→ 运行时抛NullPointerException -
Integer a = 200, b = 200; boolean eq = a == b;→ 不推荐，结果不确定（取决于是否命中缓存）
正确做法：值比较一律用 .equals()（注意空指针），或先判空再拆箱；涉及算术或逻辑运算时，确保来源非空。
包装类型本质是普通 final 类，没有运行时特殊地位；自动装箱/拆箱只是编译器帮你补了方法调用。真正容易出问题的，从来不是“怎么写”，而是“什么时候没补上 null 检查”或者“误把 == 当作数值相等用”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
