Java中级项目实体关系与对象映射核心是业务语义驱动：区分实体（User、Order）与值对象（Address、Money），合理使用@Embedded/Record；字典表优先枚举+@Enumerated；关联按需单向配置LAZY/EAGER；复杂查询用@Query+DTO；继承慎用，首选type字段+业务分支；字段映射须显式声明@Column对齐数据库语义。
Java中级项目中设计实体关系与对象映射，核心是让数据库表结构和Java类之间保持逻辑一致、可维护、易扩展。重点不在堆砌注解，而在理清业务语义、划分边界、控制映射粒度。
明确业务主次，确定实体与值对象
不是所有表都该映射为@Entity。先区分：哪些是真正有生命周期、可独立变更的“实体”（如User、Order），哪些只是描述性、不可变的“值对象”（如Address、Money）。值对象建议用@Embedded或Record封装，避免无意义的单独表和DAO。
- User 是实体，有ID、状态变更、关联多个Order
- Order 中的 shippingAddress 若不单独管理，就定义为 Address 值对象，嵌入 Order 实体
- 避免把字典表（如Gender、OrderStatus）全做成实体类，用枚举+@Enumerated更轻量
按业务场景设计关联方向与加载策略
一对多、多对一不是“双向都要写”。只在真实调用场景需要时才建立关联，并显式指定fetch = FetchType.LAZY 或 EAGER。比如Order → User 是刚需，加@ManyToOne(fetch = LAZY)；但User → Order列表，若分页查询用户时不查订单，就不该默认加载，可改用DTO投影或单独方法查询。
- 优先单向关联，减少循环依赖和序列化问题
- @OneToMany 默认是LAZY，但若没配@JoinColumn或mappedBy，JPA可能生成多余中间表
- 复杂查询用@Query + DTO构造器，比急加载整个对象图更可控
用组合优于继承，谨慎使用继承映射
遇到“管理员/普通用户”“文章/公告”这类分类，别急着用@Inheritance。多数中级项目用字段标识（type字段 + 枚举判断）+ 业务层分支更简单可靠。真要用继承，选SINGLE_TABLE策略，避免TABLE_PER_CLASS带来的查询性能和DDL碎片问题。
立即学习“Java免费学习笔记（深入）”；
- 例如User类加 userType: UserType（ADMIN, MEMBER），配合Service层switch处理
- 若必须继承，父类标注@Entity + @Inheritance(strategy = InheritanceType.SINGLE_TABLE)，子类用@DiscriminatorValue
- 避免抽象父类带@Id字段却无对应表——JPA不支持纯抽象实体
映射细节要对齐数据库语义
字段名、长度、空值、唯一约束不能只靠JPA自动生成。在@Entity类中用@Column显式声明，尤其注意：
- 字符串字段必须设length，防止H2/HSQL默认255，MySQL默认变text
- 时间字段统一用java.time.LocalDateTime，配@Column(columnDefinition = "datetime")适配MySQL
- 逻辑删除字段（isDeleted）加@Where(clause = "is_deleted = 0")实现自动过滤
- 外键字段命名统一，如userId、orderId，避免user_id混用下划线和驼峰
不复杂但容易忽略。实体不是数据库的复刻，而是业务语言的载体；映射不是越全越好，而是刚好够用、清晰可推导。
