你有没有遇到过这种情况：明明只是想把一个整数放进列表里，程序却开始“闹脾气”？或者从集合里取出一个数字，却发现它变成了对象，没法直接做计算？这背后，可能就是装箱和拆箱在悄悄起作用。
什么是装箱和拆箱
在编程中，像 int、double 这样的基本数据类型效率高，但很多容器比如 List 或集合框架只接受对象。这时候，系统就得想办法把基本类型“包装”成对象，这个过程就叫装箱。反过来，从对象中取出原始值的过程，就是拆箱。
比如你在 Java 中写下这段代码：
List<Integer> numbers = new ArrayList<>();
numbers.add(5); // 自动装箱：int 被转为 Integer
int num = numbers.get(0); // 自动拆箱：Integer 转回 int看起来很自然，对吧？就像你把一包饼干放进收纳盒（装箱），要用的时候再拿出来吃（拆箱）。可如果频繁操作，就会像反复开合收纳盒一样，拖慢速度。
别小看这点开销
想象你在超市买东西，每拿一件商品都要先填个登记表（装箱），结账时再逐个核对（拆箱），那队伍不得排到门口？程序也一样。特别是在循环里频繁装拆箱，性能损耗会很明显。
来看个例子：
Long sum = 0L;
for (long i = 0; i < Integer.MAX_VALUE; i++) {
sum += i; // 每次都发生自动装箱
}这里用的是 Long 而不是 long，意味着每次累加都会生成新的对象，内存和时间都浪费在无谓的包装上。换成基本类型，效率立马提升。
类的设计也在影响这些操作
有些类天生就和装箱拆箱打交道多，比如 Integer、Double、Boolean。它们是基本类型的“包装类”，在需要对象化的场合出场。但如果你设计一个工具类，专门处理数值运算，最好优先支持基本类型，减少中间环节。
就像你家的智能插座，可以直接识别电压电流（基本类型），非要先转成蓝牙信号再解析（对象），岂不多此一举？
怎么避免掉进坑里
写代码时留意泛型的使用。比如 Map<String, Integer> 看着没问题，但如果大量存取 int 值，不如考虑是否能用专门的 primitive map 库来避免装箱。
另外，调试时注意 null 值带来的风险。拆箱时如果对象是 null，程序会直接抛出异常：
Integer data = null;
int value = data; // 运行时报 NullPointerException这就像你打开空盒子以为里面有零食，结果摔了个跟头。
理解装箱拆箱，不只是为了修 Bug，更是为了让代码运行得更顺滑。就像了解家电原理，才能更好利用它们过日子。