统一实体类中基本类型与包装类的使用，依据字段是否允许为null选择：非空语义用基本类型（如long id），可选语义用包装类（如Boolean enabled），避免自动装箱拆箱陷阱，确保ORM映射准确与运行时安全。
重构实体类中基本类型与包装类混合声明，核心在于统一语义、规避空值风险、消除自动装箱拆箱引发的隐式性能与逻辑陷阱。所谓“类型黑洞”，指因混用 int 与 Integer、boolean 与 Boolean 等导致的 NullPointerException、缓存失效误判、集合操作异常、数据库映射歧义等问题——表面编译通过，运行时却突然坠入不可预期行为。
明确字段语义，按需选择类型
每个字段是否允许为 null，是决定使用基本类型还是包装类的根本依据：
- 业务上“必须有值”且无缺失语义（如主键 ID、创建时间戳、状态码），优先用基本类型：
long id、int status - 业务上“可选”或“未设置”（如用户中间名、订单取消原因、配置开关的启用状态），必须用包装类：
String middleName、String cancelReason、Boolean enabled - 避免为图省事把所有数字字段都声明为
Integer，尤其在高频计算或循环场景中，会触发大量无谓装箱
统一数据库映射与 ORM 行为
JPA/Hibernate 等框架对基本类型和包装类的处理差异显著：
- 基本类型字段若数据库值为
NULL，ORM 无法赋值，通常抛出DataIntegrityViolationException或静默设为默认值（如0），掩盖数据问题 - 包装类字段映射
NULL时自然为null，便于后续空值校验或业务分支判断 - 建议实体类中与数据库列一一对应的字段，严格遵循“有 NULL 可能 → 用包装类；非空约束 → 用基本类型”，并在建表 DDL 中同步定义
NOT NULL或NULL约束
警惕自动装箱/拆箱的隐式调用点
以下代码看似简洁，实为类型黑洞高发区：
-
if (user.getAge() == 18)：若getAge()返回Integer且实际为null，此处直接触发NullPointerException -
list.add(user.getScore())：若getScore()是Double，每次 add 都触发装箱；若list是ArrayList<double></double>且后续频繁遍历求和，反复拆箱会拖慢性能 - 重构方式：对可能为
null的包装类字段，显式判空再操作；对数值计算密集字段（如统计聚合），在 service 层转为基本类型处理，实体内保留包装类仅用于空值表达
善用 Lombok 与构造约束强化一致性
借助工具减少手工错误：
- 用
@Builder+@NonNull标注必填包装类字段，强制构建时非空（如@NonNull Integer age） - 对基本类型字段，配合
@Setter(AccessLevel.NONE)或私有化 setter，改用带校验的 builder 方法赋值 - 在
toString()、equals()、hashCode()生成中，确保包装类字段用Objects.equals(a, b)而非==比较
