核心在于将Enrollment作为独立实体而非单纯关联表，用复合主键或自增ID建模，封装状态变更方法校验业务规则，禁用裸setter；查询避免N+1，优先@EntityGraph；外键约束须数据库级ON DELETE RESTRICT并配合应用层校验。
Java开发课程管理系统，核心不在“系统”二字，而在“对象关系”怎么落地——不是用框架遮掩问题，而是让Course、Student、Enrollment这些类真正反映业务约束，同时能被数据库可靠持久化。
为什么不能直接用@Entity加几个@OneToMany就完事？
因为真实课程管理里，“一个学生选多门课”和“一门课被多个学生选”表面是多对多，但Enrollment表必然带状态字段（如status、grade、enrolledAt），它就不是单纯的关联表，而是一个有业务意义的实体。忽略这点，硬用@ManyToMany配JoinTable，后续加审核状态、补考记录、退课时间点时就得推倒重来。
实操建议：
- 把
Enrollment声明为独立@Entity，主键用复合键（studentId+courseId）或自增id，推荐后者——方便加索引、审计、分页 -
Course和Student各自维护@OneToMany指向Enrollment，而不是彼此直连 - 删掉所有
@ManyToMany注解，它在这里是技术债加速器
Enrollment的状态流转必须由领域逻辑控制，不能靠SQL或前端传参
常见错误：前端提交{ studentId: 101, courseId: 201, status: "WITHDRAWN" }，后端直接save()入库。结果出现“已结课的课还能退选”“未开课就给了成绩”这类违反业务规则的数据。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 在
Enrollment类里封装状态变更方法，比如enroll()、withdraw()、assignGrade(String grade) - 每个方法内部校验前置条件：
withdraw()检查当前status是否为"ENROLLED"且课程endDate未过期 - 禁止暴露
setStatus()这种裸setter；用private修饰状态字段，只允许通过行为方法修改
JPA查询要避开N+1，但别过早用@Query手写JPQL
查某个学生的全部课程，如果只写student.getEnrollments()再循环取e.getCourse()，Hibernate默认会发N条SQL查课程信息。性能崩得悄无声息。
实操建议：
- 优先用
@EntityGraph定义获取策略，在Repository方法上标注：@EntityGraph(attributePaths = {"course", "student"})
OptionalfindById(Long id); - 需要复杂筛选（如“查本学期已出成绩的课程”）时，再用
@Query，但必须包含JOIN FETCH显式关联：@Query("SELECT e FROM Enrollment e " +
"JOIN FETCH e.course c " +
"WHERE e.student.id = :studentId AND c.semester = :semester AND e.grade IS NOT NULL")
ListfindGradedEnrollments(@Param("studentId") Long studentId, @Param("semester") String semester); - 永远在
application.properties里打开spring.jpa.show-sql=true和spring.jpa.format-sql=true，每次改查询都看一眼实际执行的SQL
外键约束和级联删除必须手动对齐数据库DDL
JPA的cascade = CascadeType.REMOVE看着省事，但课程下架时如果直接删Course，可能误删还在考试中的Enrollment记录——数据库没设ON DELETE RESTRICT，应用层级联就变成单向破坏力。
实操建议：
- 所有外键在数据库建表时明确加
ON DELETE RESTRICT（或NO ACTION），让数据库兜底 - JPA侧删
Course前，先查enrollmentRepository.countByCourseId(courseId)，非零则抛BusinessException提示“该课程尚有选课记录，不可删除” - 用
flyway或liquibase管理DDL，确保enrollment表的course_id和student_id字段都有FOREIGN KEY约束，不依赖JPA自动生成
对象关系不是映射工具能自动解决的，它藏在“谁该拥有状态”“谁该发起动作”“哪条约束必须由数据库强制”这些判断里。写十行@OneToMany容易，但让Enrollment真正承担起课程管理中那个“活的连接点”的职责，才是难点所在。
