在 Java 实体类设计中，究竟该选用包装类型还是基本类型？这个问题看似简单，实则深入关系到数据语义表达、主流框架兼容性以及运行时安全性，绝非随意选择就能应对。简而言之，优先采用包装类（如 Integer、Long、Boolean）替代基本类型（int、long、boolean），核心目标在于三点：精准表达“缺失”或“未赋值”状态、与 Spring 等框架无缝协作、规避默认值带来的业务歧义，同时支持严格的空值校验机制。这并非技术炫技，而是解决实际开发中多个关键痛点的必然选择。
能够真实反映“缺失”或“未设置”的业务语义
数据库字段允许为 NULL，HTTP 请求参数也可能完全省略。如果实体类字段定义为 int age，当查询数据库返回 null 或前端未提交 age 字段时，JDBC 或 Spring MVC 会尝试将 null 拆箱为 int，直接抛出 NullPointerException。而采用 Integer age 则可以自然承接 null，后续通过判空操作明确区分“年龄为 0”与“年龄未知”两种截然不同的业务含义。这才是真正意义上的语义清晰——您肯定不希望系统将“未填写年龄”与“年龄恰好是 0”混为一谈吧？
与主流框架实现无缝协作
Spring MVC 绑定表单参数、MyBatis 映射查询结果、Jackson 解析 JSON 数据……这些场景默认都按照对象方式处理字段。具体来看：
- MyBatis 执行查询时，若数据库某列值为
NULL，它会将其设为Integer类型的null，而非强制填充默认值 0； - Spring 接收 JSON 请求体：
{"name":"张三"}中未携带"age"字段，Integer age会保持null，而int age则被自动设为 0 —— 这在语义上就产生了偏差； - 泛型集合如
List或Map无法使用基本类型，包装类型是唯一可行的方案。
框架的默认行为本就是为包装类型量身设计的，强行使用基本类型反而需要开发者自行处理各种边界情况，得不偿失。
避免隐式默认值引发的业务歧义
基本类型拥有强制默认值（int 默认为 0，boolean 默认为 false），这很容易掩盖真实的业务状态。举例说明：
- 用户注册时未填写手机号，
String phone会表示为null，但如果误用long phoneNum，它将被默认赋值为 0 —— 系统可能错误地认为存在“手机号为 0 的用户”，导致校验被绕过或业务逻辑混乱； - 订单状态字段使用
int status，默认值 0 可能被误判为“已创建”，而实际含义应为“未初始化”；改用Integer status后，null能够更清晰地表达“尚未赋值”的状态。
默认值看似简化了编码，实则在高价值业务场景中埋下了隐患。
支持更严谨的空值校验与业务逻辑判断
包装类型配合校验注解（如 @NotNull、@Min(1)）能够精准控制字段是否允许为空、取值范围等约束。例如：
@NotNull private Integer price;明确要求价格字段必须提供；@Min(1) private Integer quantity;既能校验非空，又能确保数值大于 0；- 而
int quantity即使添加了@Min(1)注解，也会因为默认值 0 导致校验失败或触发异常逻辑。
总结而言：包装类型让开发者在数据层面拥有更精细的控制力，而基本类型则将决策权交给了隐式默认值，这往往并非您所期望的结果。
