基本类型直接映射为数据库原子列或json原始值，引用类型需拆解为关联表、嵌入字段或json结构，并处理外键、循环引用及null语义差异。
基本类型和引用类型在数据持久化（比如存入数据库、序列化到文件或网络传输）时，映射方式有本质差异——不是简单“照搬”，而是取决于它们的语义、生命周期和结构特征。
基本类型：直接映射为字段值
基本类型（如 int、boolean、char、double）本身不含行为、无引用关系，值即全部。因此在持久化中通常直接对应数据库的原子列类型：
-
int → INTEGER / INT（如 MySQL 的
INT，PostgreSQL 的integer） -
boolean → TINYINT(1) 或 BOOLEAN（注意：Java 的
boolean不能为null，而数据库列常设为可空，需配合包装类Boolean处理） -
double → DOUBLE PRECISION / DECIMAL（金融场景优先用
DECIMAL避免浮点误差） -
char / String → VARCHAR / TEXT（注意：Java 的
char是单字符，但实际持久化中极少单独映射；更常见的是String，属引用类型，但因其不可变性和语义单一性，常被当作“逻辑基本类型”处理）
引用类型：需拆解或关联建模
引用类型（如 Person 类、List
-
普通 Java Bean（如 User）→ 单表映射：每个字段按类型分别映射，基本类型字段直写，引用类型字段若为另一实体（如
User.address是Address对象），则拆成外键或嵌入式字段（JPA 中用@Embedded） -
集合类（List/Map/Set）→ 关联表或 JSON 字段：一对多常用独立关联表（如
user_id+role_name）；若结构固定且不常查询内部项，也可序列化为 JSON 存入TEXT或JSON类型列（MySQL 5.7+、PostgreSQL 支持原生 JSON 查询） -
循环引用或复杂图结构 → 必须打破或显式建模：例如
A引用B，B又引用A，直接序列化会栈溢出；需用 ID 关联 + 延迟加载，或引入中间关系表
序列化场景下的映射逻辑
当数据需跨进程/网络传输（如 REST API 返回、Redis 缓存、Kafka 消息），基本类型与引用类型的处理也不同：
-
基本类型 → 直接转 JSON 原始值：
int age = 25→ JSON 中就是"age": 25 -
引用类型 → 转为 JSON 对象或数组：
User u = new User("Alice", 25)→{"name":"Alice","age":25}；其中name是String（引用类型），但 JSON 中表现为字符串字面量 -
null 处理差异明显：基本类型变量本身不能为
null（如int默认是0），但其包装类（Integer）可为null，序列化时表现为 JSON 的null；引用类型字段为null则直接输出"field": null
ORM 和框架的实际适配要点
主流 ORM（如 Hibernate、MyBatis）或序列化库（Jackson、Gson）默认按上述规则工作，但需注意几个易错点：
- 自定义类未提供无参构造器或 getter/setter → Jackson 可能反序列化失败
- 使用
final基本类型字段 → 不影响持久化，但若该字段参与主键或唯一约束，需确保初始化值合理 - 引用类型字段未标注
@Transient→ 可能被意外持久化（如临时计算结果、线程局部对象） - 日期时间类型（
LocalDateTime等）虽是引用类型，但框架通常内置转换器映射为TIMESTAMP，无需手动拆解
