自动装箱与拆箱简化基本类型和包装类转换，提升可读性但带来对象创建、空指针和性能开销；需警惕==比较陷阱、null拆箱崩溃及高频装拆场景，性能敏感处优先用原始类型或专用集合。
自动装箱与拆箱让基本类型和包装类之间的转换“看不见”，代码写起来更顺手，但背后有真实开销。它不是语法糖那么简单，而是一把双刃剑——用得巧，提升可读性；用得莽，悄悄拖慢程序。
让代码更简洁：省掉冗余转换，聚焦逻辑
没有自动装箱时，往集合里存 int 得手动包装：
- List
list = new ArrayList();
list.add(Integer.valueOf(42)); // 显式装箱 - int value = list.get(0).intValue(); // 显式拆箱
有了自动机制，直接写：
- list.add(42); // 编译器自动插进 valueOf
- int value = list.get(0); // 编译器自动调用 intValue
这种简化在泛型集合、方法参数传递、算术混合运算（如 Integer x = 5; int y = 3; int z = x + y;）中特别明显，减少样板代码，降低出错概率。
性能代价藏在对象创建与空值检查里
每次自动装箱都可能新建对象，尤其超出缓存范围时：
- Integer.valueOf(100) → 复用缓存对象（-128 到 127）
- Integer.valueOf(1000) → 每次 new Integer(1000)，触发堆分配和 GC 压力
- 拆箱前若对象为 null，运行时抛出 NullPointerException（不是编译错误）
高频场景下（如循环中反复装拆）会放大影响。例如对百万级 int 数组做流式处理：IntStream.of(arr).boxed().mapToInt(x -> x * 2).toArray()，中间的 boxed() 就是批量装箱，开销可观。
哪些地方容易踩坑
看似安全的写法，实际暗藏风险：
- == 比较陷阱：Integer a = 127, b = 127 → a == b 为 true；但 a = 128, b = 128 → a == b 为 false（缓存失效，对象不同）
- null 拆箱崩溃：Integer x = null; int y = x; → 直接抛 NPE，尤其在 Optional 或数据库查询结果为空时易发
-
泛型容器+原始计算：List
list = ...; int sum = list.stream().mapToInt(i -> i).sum(); 这里每个 i 都要拆箱，不如用 IntArrayList 等专用结构
兼顾简洁与性能的实用建议
不必因噎废食，关键在意识和选择：
- 日常业务逻辑中放心用，可读性收益远大于微小开销
- 性能敏感路径（如高频循环、底层工具类）优先使用原始类型数组或专门的原始集合库（如 Eclipse Collections、Trove）
- 涉及比较时统一用 equals()，避免 ==；拆箱前加 null 判断或用 Objects.requireNonNull
- 注意 Integer.valueOf 的缓存边界，-128~127 是安全区，超范围慎用于频繁复用场景
