应设计独立的选课实体Enrollment，包含studentId、courseId和enrollDate，Student和Course类仅保留基本信息；内存模拟时用HashMap按ID索引学生和课程，选课记录用List或Map存储；addEnrollment需校验学生存在、课程存在及不重复选课；控制台输入统一用nextLine()配合trim()和类型转换。
学生类和课程类怎么设计才支持选课关系
学生和课程不是孤立实体，必须体现“多对多”关联：一个学生可选多门课，一门课可被多个学生选。直接在 Student 里存 List 或反过来，会导致数据冗余、更新困难、无法记录选课时间等业务信息。
正确做法是引入独立的选课实体 Enrollment，它至少包含：studentId、courseId、enrollDate（可选）。这样既解耦，又便于扩展（比如加成绩、状态字段）。
-
Student类只保留基本信息：id、name、age 等，不持有课程列表 -
Course类同理：id、title、credit 等，不维护学生列表 - 所有“谁选了哪门课”的逻辑，统一通过
Enrollment实例操作
用 ArrayList 还是 Map 存储数据合适
纯内存模拟（无数据库）时，选课系统核心是快速查“某学生选了哪些课”或“某课有哪些学生”。ArrayList 查找是 O(n)，频繁查询会卡顿；而用 HashMap 按 ID 建索引，能实现 O(1) 查找。
推荐组合使用：
立即学习“Java免费学习笔记（深入）”；
- 用
Map存所有学生，key 是studentId - 用
Map存所有课程，key 是courseId - 用
List存选课记录（也可升级为Map，key 拼成"s1_c2"）
注意：不要用 TreeMap 除非需要排序；也不要为图省事把全部数据塞进一个 ArrayList 然后每次 stream().filter() —— 业务稍一复杂就不可维护。
addEnrollment() 方法里最容易漏掉的校验
用户输入 ID 后直接调 addEnrollment(studentId, courseId)，但真实场景中必须拦截三类错误：
- 学生不存在 → 查
students.get(studentId)是否为null - 课程不存在 → 查
courses.get(courseId)是否为null - 重复选课 → 遍历当前
enrollments，检查是否已有studentId和courseId都匹配的记录
漏掉任一校验，后续 getStudentCourses() 就可能抛 NullPointerException 或返回脏数据。建议把这三步封装成私有方法，比如 validateStudentAndCourse(long sid, long cid)，避免散落在多处。
public boolean addEnrollment(long studentId, long courseId) {
if (validateStudentAndCourse(studentId, courseId)) {
Enrollment e = new Enrollment(studentId, courseId, new Date());
enrollments.add(e);
return true;
}
return false;
}
控制台交互时 Scanner.nextLine() 的坑怎么绕开
用 Scanner 做命令行菜单时，如果先调 nextInt() 读选项编号，再用 nextLine() 读学生姓名，后者会立刻返回空字符串——因为 nextInt() 不吞回车符，nextLine() 直接读到换行就结束了。
最稳妥的解法是：统一用 nextLine()，然后手动转类型：
- 读整数：
Integer.parseInt(scanner.nextLine().trim()) - 读长整型 ID：
Long.parseLong(scanner.nextLine().trim()) - 所有输入都加
trim()，防用户多敲空格
别依赖 hasNextInt() 做判断，它不阻塞，容易跳过输入；也别在 nextInt() 后补一句 scanner.nextLine() 来“清缓存”，这种写法在嵌套输入时极易出错。
真实项目里，选课不只是增删查，还要处理退课、冲突检测、容量限制、成绩录入……但所有这些，都建立在“关系模型清晰”和“基础校验扎实”之上。初学者最容易花两小时调通一个 NullPointerException，却忽略它本该在 addEnrollment() 第一行就被拦住。
