Java为何推荐使用包装类而非基本类型？

Java推荐使用Integer等包装类而非int基本类型，核心在于解决基本类型无法作为对象使用的根本限制：只有当需要将数字存入集合、充当Map键、参与泛型、明确表达“未设置”（即允许null）或与框架（如Spring、MyBatis）协同处理缺失值时，Integer才不可替代；而自动装箱/拆箱虽简化了编码，却暗藏==比较陷阱、空指针风险和类型推导误区；性能敏感场景应优先用int，但日常开发中为保障语义清晰、避免边界逻辑漏洞和框架兼容问题，DTO字段、API参数、数据库映射等更应果断选用Integer——关键不是盲目面向对象，而是根据“值计算”还是“数据载体”的角色，精准选择最能准确表达业务意图的类型。

Java里什么时候必须用Integer而不是int

只有在需要把数字当对象用的时候——比如放进ArrayList、作为Map的键、参与泛型、或者允许为null时，才非用Integer不可。

基本类型int压根不是对象，不能调方法、不能判null、也不能被JVM当作引用传递。你写list.add(123)看着像在加int，其实背后是自动装箱成Integer，编译器帮你偷偷干的。

• 集合类（ArrayList、HashSet、HashMap等）只接受引用类型，int直接报错：no suitable method found for add(int)
• 泛型擦除后只剩Object，int无法向上转型，所以List语法根本不存在
• 想表达“这个值还没设置”，用Integer可以赋null；int只能设默认值0，语义模糊

自动装箱/拆箱到底在哪儿悄悄发生

不是所有地方都安全触发。最常掉坑里的，是==比较和条件运算符?:。

比如Integer a = 127; Integer b = 127; a == b结果是true，但换成128就变成false——因为JVM对-128~127之间的Integer做了缓存，超出范围就新建对象，==比的是引用而非值。

• 永远用.equals()比较两个Integer，别信==
• Integer x = null; int y = x;会抛NullPointerException，拆箱不检查null
• boolean flag = true; Integer v = flag ? 100 : null;——这里100会被自动装箱，但整个表达式类型是Integer，没问题；可如果写成flag ? 100 : 200，结果就是int，再赋给Integer变量又触发一次装箱

性能敏感场景下int还是Integer怎么选

高频循环、大量数值计算、或内存受限（如Android低端机、实时数据处理），优先用int。包装类多一层对象开销：堆分配、GC压力、额外字段（比如Integer除了value还带class指针、锁标记等）。

但别为了这点性能过早优化。日常业务代码里，该用Integer的地方不用，反而要不停手动转、补判空、绕开泛型，维护成本更高。

• 数组、for循环计数器、数学运算中间变量——用int
• DTO字段、JSON序列化字段、配置项解析结果——用Integer（方便区分“没传”和“传了0”）
• 用Optional代替Integer来明确表达“可能为空”，比靠null猜意图更可靠

Spring/MyBatis这类框架里Integer的典型误用

框架层面对null和0的处理逻辑经常不同。比如MyBatis的能正常过滤未传ID，但如果你把参数声明成int id，哪怕前端没传，后端也收了个默认0，test="id != 0"就容易漏判。

再比如Spring MVC接收JSON，{"age":null}能绑定到Integer age，但绑定不到int age，直接400报错。

• Controller入参、Service方法参数、Entity字段——只要可能为空或需区分缺失/零值，统一用Integer
• 数据库字段为INT NULL，对应Java字段别用int，否则ORM读到NULL时会出异常或静默设为0
• 单元测试里故意传null验证边界逻辑，用int根本构造不出这个场景

包装类不是为了“面向对象而面向对象”，是为了解决基本类型做不到的事。该用的时候不用，问题藏得深；不该用硬套，又平添麻烦。关键在分清哪里是值，哪里是数据载体。

本篇关于《Java为何推荐使用包装类而非基本类型？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！