学生选课系统需用enrollment实体显式建模三元关系以支持选课时间等业务字段，避免@manytomany丢弃中间表字段；须用联合唯一索引+select for update+完整事务边界保障并发安全。
学生选课系统不是“用Java写几个类就能跑起来”的项目，关键在对象关系建模是否贴合业务约束——比如一个学生不能重复选同一门课、课程容量超限应拒绝插入、退课后学分需实时更新。这些都不是靠ArrayList或HashMap硬编码能稳住的。
用JPA映射“学生-课程-选课”三元关系时，为什么@ManyToMany直接映射会丢掉选课时间？
因为@ManyToMany只描述两端关联，无法承载中间表（如enrollment）的业务字段。一旦你需要记录selectedAt、grade、status（待审核/已通过/已退），就必须拆成两个@OneToMany，显式建模Enrollment实体。
常见错误是强行用@JoinTable加@Column往关联表塞字段，JPA会忽略——关联表在JPA里只是桥接结构，不支持自定义列。
- 正确做法：声明
Student→Enrollment（@OneToMany），Course→Enrollment（@OneToMany），Enrollment含@ManyToOne双向回引 -
Enrollment主键建议用复合主键（@EmbeddedId）或代理键（@Id+studentId/courseId字段） - 数据库层面，
enrollment表必须设联合唯一索引：UNIQUE (student_id, course_id)，否则JPA层校验可能被并发绕过
Spring Data JPA查“某学生所有已选课程及成绩”时，N+1查询怎么破？
典型写法studentRepository.findById(id).get().getEnrollments()会触发1次查学生、N次查每条选课对应的课程信息。即使加了@JsonIgnore或fetch = FetchType.EAGER，也容易因级联加载过度拖垮内存。
立即学习“Java免费学习笔记（深入）”；
真正可控的方式是用@Query手写JPQL或原生SQL，配合JOIN FETCH一次性拉平：
@Query("SELECT DISTINCT e FROM Enrollment e " +
"JOIN FETCH e.course c " +
"WHERE e.student.id = :studentId AND e.status = 'ENROLLED'")
List<Enrollment> findEnrolledCourses(@Param("studentId") Long studentId);- 必须加
DISTINCT：JOIN FETCH在一对多时会产生笛卡尔积，导致重复对象 - 避免在
Enrollment上直接@ManyToOne(fetch = FetchType.EAGER)：全局 eager 会污染所有查询场景 - 如果还要查课程教师、院系等更多层级，优先考虑DTO投影（
SELECT NEW com.example.CourseDetail(...)），而非无限FETCH
处理“选课冲突”时，用Java层校验还是数据库约束更可靠？
两者都要，但顺序和分工必须明确：Java层做快速前置过滤（如检查课程是否已结课、学生学分是否超标），数据库层用唯一约束和事务锁兜底。
典型并发问题：两个请求同时选同一门只剩1个名额的课，Java层查剩余容量=1 → 都允许提交 → 数据库写入后只剩1条成功，另一条抛ConstraintViolationException。
- 关键动作：在
EnrollmentService中对course_id加synchronized没用（分布式环境失效），应改用SELECT ... FOR UPDATE锁定课程行 - JPA中可用
@Lock(LockModeType.PESSIMISTIC_WRITE)查课程再更新容量，或直接执行原生SQL：UPDATE course SET capacity = capacity - 1 WHERE id = ? AND capacity > 0，检查updateCount == 1 - 不要依赖
@Version乐观锁解决选课冲突：它防的是“先读后写覆盖”，不是“并发争抢资源”
最常被跳过的细节是事务边界——@Transactional必须包住“查容量→扣容量→建选课记录→发通知”整个链条，且传播行为用REQUIRED（默认），别被嵌套调用意外切出事务。一旦漏掉，数据库约束还在，但业务状态就可能不一致了。
