学生、课程与选课记录构成多对多关系，需通过SelectRecord中间实体及studentRecords、courseRecords两个Map维护双向关联，配合Set去重和HashMap高效查询，选课退课须原子性同步更新三方数据，业务逻辑应封装在服务类中以保障可维护性与可扩展性。
学生选课系统的核心在于准确建模“学生”“课程”“选课记录”三者之间的关系，并用Java集合高效表达和操作这些关系。关键不是堆砌功能，而是理清谁属于谁、谁关联谁、数据如何增删查改才既安全又高效。
学生与课程：一对多还是多对多？
一个学生可选多门课，一门课也可被多个学生选择——这是典型的多对多关系。不能直接用List
正确做法是引入中间实体（如SelectRecord），同时持有studentId和courseId；再配合两个映射结构：
- Map
> studentRecords：以学号为键，查该生所有选课记录 - Map
> courseRecords：以课号为键，查该课所有选课记录
这样增删选课时只需操作SelectRecord列表，两端统计、查询都清晰可控。
立即学习“Java免费学习笔记（深入）”；
用Set保证选课不重复，用Map加速查找
学生不能重复选同一门课。若用List保存某生已选课号，每次添加前需遍历判断——O(n)效率低。换成HashSet
同样，课程信息按课号管理，用HashMap
选课/退课：原子操作 + 双向同步
一次选课不是只往学生列表里加课，也不是只往课程列表里加人，而是要同步更新三个地方：
- 在SelectRecord集合中新增一条记录
- 向该生的studentRecords.get(studentId)列表中添加该记录
- 向该课的courseRecords.get(courseId)列表中添加该记录
退课则反向移除这三条关联。漏掉任一环节，就会出现“学生显示已选但课程名单里没有”，或“课程显示有人选但学生查不到”这类逻辑错乱。
内存管理与业务边界要分明
整个系统通常运行在单机JVM内，所有集合都是内存对象。这意味着：
- 不重启就不会丢数据，但也意味着没做持久化——关机即清空，仅适合教学演示
- 学生、课程、选课记录应定义为独立类，字段私有，提供必要getter/setter，避免外部随意修改内部状态
- 选课服务类（如CourseSelectionService）应封装所有add/drop/query逻辑，不暴露底层Map或List给UI层
这样既便于单元测试，也方便后续扩展数据库支持——只需替换集合操作为JDBC或MyBatis调用，业务逻辑几乎不动。
