应设计独立的选课实体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) 查找。

推荐组合使用：

• 用 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() 第一行就被拦住。