Java持久化应优先使用包装类而非基本类型，以准确映射NULL语义：数据库中用getInteger()而非getInt()，ORM实体字段声明为Integer，序列化和JSON中包装类可表示null，确保数据语义一致性。
Java 中基本类型和包装类本身不直接参与数据持久化，它们只是内存中的值。要实现持久化，必须把它们存入外部存储（如数据库、文件、缓存等）。关键不是“怎么转换”，而是“怎么把值安全、正确地写入和读出持久化介质”。转换只是中间一环，且通常自动发生。
数据库场景：JDBC 或 ORM 框架中自动处理
使用 JDBC 时，PreparedStatement 的 setXxx() 方法接受基本类型或包装类（如 setInt(1, 5) 或 setInt(1, Integer.valueOf(5))），底层会自动拆箱；而 ResultSet.getXxx()（如 getInt()）返回基本类型，若数据库字段为 NULL，则返回 0 —— 这有风险。更安全的做法是用包装类对应的方法（如 getInteger()），它返回 Integer，NULL 映射为 null：
-
rs.getInt("age")→ 基本类型int，NULL 被转成 0（易掩盖业务 NULL） -
rs.getInteger("age")→ 包装类Integer，NULL 返回null，可准确区分“无值”和“值为 0”
在 MyBatis、Hibernate 等 ORM 中，实体类字段用包装类（如 private Integer age;）更合理，框架能正确映射数据库 NULL；若用 int age，NULL 会被强制转为 0 或抛异常，影响数据语义。
序列化到文件或网络：推荐用包装类 + 标准序列化机制
Java 原生序列化（ObjectOutputStream）要求对象实现 Serializable，基本类型不能直接序列化，但包装类可以。例如：
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 保存：将
Integer、Boolean等包装类实例写入文件，无需手动转换 - 读取：反序列化后直接得到包装类对象，用
.intValue()等按需获取基本类型 - 注意：基本类型字段在可序列化类中会被自动处理（如
int x;），但若字段可能为 NULL（如来自数据库），应声明为Integer x;并确保类支持 null 安全
JSON / XML 等文本格式：依赖序列化库的空值策略
用 Jackson、Gson 等库时，基本类型字段无法表示 null，而包装类可以：
-
private int status;→ JSON 中始终输出数字，哪怕数据库是 NULL（库可能默认设为 0） -
private Integer status;→ JSON 中可输出"status": null，保留原始语义 - Jackson 默认对包装类 null 值序列化为
null，反序列化时也正确还原为null；基本类型则会报错或跳过
因此，在 DTO、Entity 或配置类中，优先使用包装类定义可能为空的数值、布尔、字符字段。
持久化前的校验与转换建议
实际开发中，不建议在持久化逻辑里频繁手动调用 Integer.valueOf() 或 .intValue()。更合理的做法是：
- 输入层（如 Controller）接收参数时，用包装类（如
@RequestParam Integer id），让框架自动绑定 null - 业务逻辑中判断是否为 null，再决定如何处理（如抛异常、设默认值、跳过保存）
- 写入前统一校验，避免把 null 写入非空字段；读取后根据业务需要决定是否自动拆箱
- 数据库设计层面，明确哪些字段允许 NULL，并在 Java 类中用对应包装类匹配
不复杂但容易忽略：持久化的核心是语义一致性，而不是类型转换技巧。选对类型（包装类 vs 基本类型），配对好存储介质的 null 行为，比写一堆 == null ? null : x.intValue() 更可靠。
