Java+MySQL学生选课系统避坑指南：控制台交互开发中的5个常见错误

Java+MySQL学生选课系统避坑指南：控制台交互开发中的5个常见错误

如果你正在用Java和MySQL捣鼓一个控制台的学生选课系统，大概率会经历一个从“信心满满”到“怀疑人生”的过程。这太正常了，我当年做第一个课程设计时，数据库连接报错能卡我整整一个下午。控制台项目看似简单，没有花里胡哨的前端界面，但恰恰因为如此，所有逻辑、数据交互和异常处理的细节都暴露无遗，任何一个环节的疏忽都会导致程序在运行时给你一个冷冰冰的报错。这篇文章，我想和你聊聊那些新手开发者最容易掉进去的五个“坑”，这些坑不仅关乎代码能否跑起来，更关乎你的系统是否健壮、安全，以及未来是否易于维护。我会结合具体的场景和代码片段，告诉你问题出在哪，以及更优雅的解决方案是什么。

1. 数据库连接与资源管理：从“能用”到“可靠”

很多教程和示例代码里，数据库连接（Connection）、语句（Statement/PreparedStatement）和结果集（ResultSet）的创建与关闭，常常被写在一个方法里，用完就丢。这在简单的演示里没问题，但一旦你的系统需要处理多次请求，或者在高并发（哪怕只是模拟）的场景下，这种写法就是灾难的源头。

最常见的错误姿势：在每个DAO（数据访问对象）方法内部直接获取连接，执行SQL，然后关闭。看起来逻辑清晰，对吧？但问题在于，你无法保证连接被正确关闭。看看这段典型的“问题代码”：

public class ProblematicUserDAO { public User getUserById(int id) throws SQLException { Connection conn = null; Statement stmt = null; ResultSet rs = null; try { // 1. 加载驱动（通常已过时） Class.forName("com.mysql.cj.jdbc.Driver"); // 2. 建立连接 conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/student_system", "root", "password"); stmt = conn.createStatement(); String sql = "SELECT * FROM user WHERE userid = " + id; // 注意这里的字符串拼接！ rs = stmt.executeQuery(sql); if (rs.next()) { // ... 组装User对象 } } catch (ClassNotFoundException e) { e.printStackTrace(); } finally { // 3. 关闭资源 if (rs != null) rs.close(); if (stmt != null) stmt.close(); if (conn != null) conn.close(); } return null; } }

这段代码至少有三个致命伤：

1. SQL注入漏洞：直接拼接用户输入的id到SQL语句中，如果id来自用户输入，恶意用户输入1 OR 1=1，你的查询逻辑就崩了。
2. 硬编码配置：数据库URL、用户名、密码直接写在代码里，换个环境就得改代码，极不灵活。
3. 资源关闭顺序不当且可能遗漏：虽然有关闭，但在复杂的业务逻辑或异常分支中，很容易漏掉某个资源的关闭。而且，关闭顺序应该是ResultSet->Statement->Connection，与创建顺序相反。

更优雅的解决方案：连接池与工具类

对于学生项目，我们不必上Spring Data JPA那么重的框架，但引入一个轻量级的连接池（如HikariCP）和编写一个可靠的数据库工具类是绝对必要的。

首先，通过Maven引入HikariCP依赖：

<dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId> <version>5.0.1</version> </dependency>

然后，创建一个DatabaseUtil类来管理连接池：

import com.zaxxer.hikari.HikariConfig; import com.zaxxer.hikari.HikariDataSource; import java.sql.Connection; import java.sql.SQLException; public class DatabaseUtil { private static final HikariDataSource dataSource; static { HikariConfig config = new HikariConfig(); // 从配置文件读取，避免硬编码 config.setJdbcUrl("jdbc:mysql://localhost:3306/student_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai"); config.setUsername("your_username"); config.setPassword("your_password"); config.setMaximumPoolSize(10); // 连接池大小 config.setMinimumIdle(5); config.setConnectionTimeout(30000); // 连接超时30秒 config.setIdleTimeout(600000); // 空闲连接超时10分钟 config.setMaxLifetime(1800000); // 连接最大生命周期30分钟 config.addDataSourceProperty("cachePrepStmts", "true"); config.addDataSourceProperty("prepStmtCacheSize", "250"); config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048"); dataSource = new HikariDataSource(config); } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } // 一个安全的资源关闭方法 public static void closeResources(AutoCloseable... resources) { for (AutoCloseable resource : resources) { if (resource != null) { try { resource.close(); } catch (Exception e) { // 记录日志，但不要抛出异常影响主流程 System.err.println("关闭资源时发生错误: " + e.getMessage()); } } } } }

提示：AutoCloseable是Java 7引入的接口，Connection、Statement、ResultSet都实现了它。使用可变参数和try-with-resources语句能让资源管理更安全。

现在，你的数据访问方法可以写得既安全又简洁：

public class SafeUserDAO { public User getUserById(int id) { String sql = "SELECT * FROM user WHERE userid = ?"; try (Connection conn = DatabaseUtil.getConnection(); PreparedStatement pstmt = conn.prepareStatement(sql)) { pstmt.setInt(1, id); // 防止SQL注入 try (ResultSet rs = pstmt.executeQuery()) { if (rs.next()) { User user = new User(); user.setId(rs.getInt("userid")); user.setName(rs.getString("name")); // ... 设置其他属性 return user; } } } catch (SQLException e) { // 这里应该记录日志，而不是简单打印 e.printStackTrace(); throw new RuntimeException("查询用户失败", e); // 或自定义业务异常 } return null; } }

使用try-with-resources语法，你完全不需要手动调用close()，Java会自动在try块结束时以正确的顺序关闭它们。这才是现代Java数据库编程该有的样子。

2. 事务处理的缺失与混乱：数据一致性的隐形杀手

在选课系统中，很多操作不是单条SQL能完成的。例如“学生选课”这个核心功能，它至少涉及两个步骤：

1. 检查该学生是否已选过此课（或是否达到选课上限）。
2. 向选课表（如socre或student_course）插入一条记录。

如果这两步之间没有事务保护，会发生什么？想象一下，第一步检查通过，但在执行第二步插入时，数据库连接突然断开，或者发生了其他异常。结果就是：系统认为学生可以选课（因为第一步过了），但实际上选课记录并没有成功写入数据库。学生端看到选课成功，但老师端名单里没有他，这就是典型的数据不一致。

错误示范：在原始的Student.chooseCourse方法中，我们看到了一个循环插入课程的过程，但整个方法并没有开启事务。

// 原始代码片段（简化） for (Integer courseId : selectedCourses) { String sql = "INSERT INTO socre (userid, courseid) VALUES (" + stuNum + ", '" + courseId + "')"; int res = stmt.executeUpdate(sql); // 每次插入都是独立的事务 if (res < 1) { System.out.println("课程选择失败，请重新选择！"); return; // 这里直接返回，之前成功插入的记录不会回滚！ } }

如果插入第三门课时失败，前两门课的记录已经永久留在数据库里了。学生可能只选到了部分课程，这与业务逻辑“要么全选，要么全不选”相悖。

正确的姿势：显式管理事务

我们需要将多个数据库操作捆绑成一个原子操作。在JDBC中，这通过Connection对象的setAutoCommit(false)、commit()和rollback()来实现。

下面是一个改造后的chooseCourse方法的事务版本：

public void chooseCourseWithTransaction(String username, List<Integer> courseIds) throws SQLException { Connection conn = null; PreparedStatement pstmt = null; try { conn = DatabaseUtil.getConnection(); conn.setAutoCommit(false); // 1. 开启事务 String checkSql = "SELECT COUNT(*) FROM socre WHERE userid = ? AND courseid = ?"; String insertSql = "INSERT INTO socre (userid, courseid, score) VALUES (?, ?, NULL)"; // 成绩初始为NULL pstmt = conn.prepareStatement(checkSql); for (Integer courseId : courseIds) { // 检查是否已选 pstmt.setInt(1, getStuNum(username)); pstmt.setInt(2, courseId); try (ResultSet rs = pstmt.executeQuery()) { if (rs.next() && rs.getInt(1) > 0) { throw new SQLException("学生已选择课程ID: " + courseId); } } } // 执行批量插入 pstmt = conn.prepareStatement(insertSql); for (Integer courseId : courseIds) { pstmt.setInt(1, getStuNum(username)); pstmt.setInt(2, courseId); pstmt.addBatch(); // 加入批处理 } int[] results = pstmt.executeBatch(); // 执行批处理 // 检查批处理结果 for (int result : results) { if (result != Statement.SUCCESS_NO_INFO && result <= 0) { throw new SQLException("选课操作执行失败"); } } conn.commit(); // 2. 提交事务 System.out.println("选课成功！"); } catch (SQLException e) { if (conn != null) { try { conn.rollback(); // 3. 发生异常，回滚事务 System.out.println("选课失败，已回滚所有操作。错误信息: " + e.getMessage()); } catch (SQLException rollbackEx) { System.err.println("回滚事务时发生错误: " + rollbackEx.getMessage()); } } throw e; // 将异常继续向上抛出 } finally { DatabaseUtil.closeResources(pstmt, conn); } }

注意：事务的范围要合理。不要为了“安全”就把整个用户会话都放在一个事务里，这会导致数据库连接被长时间占用，严重影响性能。事务应只涵盖需要原子性的一组数据库操作。

为了更清晰地理解事务在选课流程中的作用，我们可以看下面这个对比表格：

3. 角色权限与业务逻辑的混淆：在控制台里构建清晰的边界

在控制台系统中，权限检查很容易被忽略，因为所有代码都在一起。但混淆角色权限会导致严重的业务逻辑错误和安全问题。例如，在原始的Teacher类中，addStudent()方法允许老师添加学生。这听起来合理，但仔细想想：“添加学生”这个操作，真的应该属于教师的核心职责吗？在大多数教务系统中，学生信息的录入和初始化通常由管理员或教务人员在学期初完成。教师的核心职责是教学和评分。

更常见的错误是，在代码中通过简单的role字段判断后，就直接跳转到对应角色的菜单，但后续的功能方法里却没有再次校验当前登录用户是否真的有权限执行某个操作。比如，一个学生如果通过某种方式（比如直接调用方法）进入了teacherUi，他理论上就能执行“录入成绩”的操作，这显然是灾难性的。

问题根源：权限校验与业务逻辑深度耦合，且校验不完整。

解决方案：职责分离与入口校验

1. 明确角色职责：在系统设计之初，就明确每个角色的核心职责。例如：

   • 管理员：系统维护、用户管理（增删改）、课程/班级管理。
   • 教师：查看任教课程、管理所选课程的学生名单、录入/修改成绩、查看教学统计。
   • 学生：查看可选课程、选课/退课、查看个人课表与成绩。

2. 设计独立的权限校验层：不要在每一个业务方法里都写if (currentUser.getRole() != 2) { return; }。我们可以设计一个简单的权限校验工具，或者在每个请求的入口处进行拦截。

对于控制台程序，一个实用的方法是在主菜单分发后，每个角色的“后台”方法里，持有当前登录用户的上下文信息（如User对象），并在执行敏感操作前进行二次确认。虽然控制台没有Web层的Filter或Interceptor，但我们可以模拟这种思想。

public class AuthContext { private static ThreadLocal<User> currentUser = new ThreadLocal<>(); public static void setCurrentUser(User user) { currentUser.set(user); } public static User getCurrentUser() { return currentUser.get(); } public static void clear() { currentUser.remove(); } // 一个简单的权限检查方法 public static void requireRole(int expectedRole) throws SecurityException { User user = getCurrentUser(); if (user == null || user.getRole() != expectedRole) { throw new SecurityException("权限不足：需要角色" + expectedRole); } } } // 在登录成功后设置 User loggedInUser = loginService.login(username, password); AuthContext.setCurrentUser(loggedInUser); // 在教师后台的方法中校验 public void teacherAddScore(String courseName, int studentId, int score) { try { AuthContext.requireRole(2); // 2代表教师角色 // ... 真正的录入成绩逻辑 } catch (SecurityException e) { System.out.println("错误: " + e.getMessage()); return; } }

3. 重构菜单与功能映射：确保每个角色看到的菜单，只包含他有权执行的操作。在控制台中，这意味着你的teacherUi()方法里，不应该出现“添加学生”这样的菜单项。如果教师确实需要有“添加学生到我的课程”的功能，那这个功能的方法名和逻辑也应该是addStudentToMyCourse(int courseId, String studentNo)，并且内部要校验该课程是否由当前教师任教。

4. 输入验证与异常处理的敷衍了事：构建健壮的系统交互

控制台程序通过Scanner获取用户输入，这里是错误和攻击的温床。直接使用rader.next()或rader.nextInt()而不加验证，程序崩溃是家常便饭。

典型问题场景：

1. 类型错误：当提示输入数字（如课程ID）时，用户输入了字母，nextInt()会抛出InputMismatchException，程序直接终止。
2. 业务逻辑错误：输入的学生ID不存在，但代码依然尝试用它去关联外键，导致SQLException。
3. 边界错误：输入的成绩为-10或120，不符合0-100的常规范围。

原始代码中的风险点：

System.out.print("请输入课程学分："); courseScore = rader.nextInt(); // 如果输入非数字，程序崩溃 System.out.print("请输入任课老师："); courseTeacher = rader.next(); // 如果老师名不存在，后续SQL会失败

强化你的输入处理：

你需要一个健壮的输入工具类，它能够处理各种无效输入，并引导用户重新输入，直到获得有效数据。

import java.util.Scanner; import java.util.function.Predicate; public class ConsoleInputHelper { private static final Scanner scanner = new Scanner(System.in); // 获取一个整数，并提供验证规则 public static int getInt(String prompt, Predicate<Integer> validator) { while (true) { System.out.print(prompt); if (scanner.hasNextInt()) { int value = scanner.nextInt(); scanner.nextLine(); // 消耗掉换行符 if (validator.test(value)) { return value; } else { System.out.println("输入的值不符合要求，请重新输入。"); } } else { System.out.println("输入错误，请输入一个有效的整数。"); scanner.next(); // 消耗掉无效的输入 } } } // 获取一个非空字符串 public static String getNonEmptyString(String prompt) { String input; do { System.out.print(prompt); input = scanner.nextLine().trim(); if (input.isEmpty()) { System.out.println("输入不能为空，请重新输入。"); } } while (input.isEmpty()); return input; } // 获取一个在给定范围内的整数 public static int getIntInRange(String prompt, int min, int max) { return getInt(prompt, value -> value >= min && value <= max); } // 简单的Yes/No选择 public static boolean getYesNo(String prompt) { while (true) { System.out.print(prompt + " (y/n): "); String input = scanner.nextLine().trim().toLowerCase(); if (input.equals("y") || input.equals("yes")) { return true; } else if (input.equals("n") || input.equals("no")) { return false; } System.out.println("请输入 'y' 或 'n'。"); } } }

现在，你的业务代码可以这样写，既安全又清晰：

// 添加课程时，安全地获取输入 public void addCourseSafely() throws SQLException { String courseName = ConsoleInputHelper.getNonEmptyString("请输入课程名："); int courseScore = ConsoleInputHelper.getIntInRange("请输入课程学分（1-10）：", 1, 10); String teacherName = ConsoleInputHelper.getNonEmptyString("请输入任课老师姓名："); // 先验证老师是否存在 if (!teacherService.existsByName(teacherName)) { System.out.println("错误：老师 '" + teacherName + "' 不存在。"); return; } // 再执行数据库操作 courseService.addCourse(courseName, courseScore, teacherName); }

异常处理的原则：不要简单地e.printStackTrace()或者吞掉异常。要区分可恢复的业务异常（如“用户不存在”、“密码错误”）和不可恢复的系统异常（如数据库连接断开）。对于业务异常，给用户友好的提示；对于系统异常，记录详细的日志（而不是打印到控制台），并可能向上抛出或进行降级处理。

try { // ... 业务操作 } catch (SQLIntegrityConstraintViolationException e) { // 违反唯一约束、外键约束等，属于可预见的业务异常 System.out.println("操作失败：数据约束冲突，可能是信息重复或关联项不存在。"); // 可以记录更详细的日志到文件 logger.warn("数据约束冲突: " + e.getMessage()); } catch (SQLException e) { // 其他数据库异常，可能是更严重的系统问题 System.err.println("系统错误：数据库操作异常，请联系管理员。"); logger.error("数据库操作失败", e); // 使用日志框架记录错误堆栈 throw new RuntimeException("系统内部错误", e); // 或转换为自定义运行时异常 } catch (Exception e) { // 捕获其他所有未预料到的异常 System.err.println("发生未知错误。"); logger.error("未知异常", e); }

5. 代码结构混乱与职责不清：从“面条代码”到清晰架构

很多初学者写的控制台项目，喜欢把所有代码都塞进一个或几个巨大的类里，比如一个Main类包含所有菜单，一个Manager类包含所有管理员操作。这种“面条式代码”在功能少的时候还能勉强运行，但随着功能增加，它会迅速变得难以阅读、难以调试、难以修改。

原始代码结构的问题：

• view类：承担了显示菜单、接收输入、身份验证、路由跳转（调用不同角色的后台方法）等多重职责，非常臃肿。
• Manager、Teacher、Student类：除了实体属性，还包含了与该角色相关的所有业务逻辑和数据访问代码，违反了单一职责原则。
• 数据库操作分散：在每个需要操作数据库的方法里，都有一套获取连接、创建语句、执行、关闭的模板代码，造成大量重复。

重构建议：分层架构

即使是一个控制台项目，我们也应该有意地采用分层思想，这会让你的代码立刻变得专业和可维护。一个典型的三层架构如下：

项目结构示例： src/ ├── main/ │ ├── java/ │ │ ├── com/ │ │ │ └── yourdomain/ │ │ │ └── studentsystem/ │ │ │ ├── model/ # 实体类 (User, Course, Score等) │ │ │ ├── dao/ # 数据访问层接口和实现 │ │ │ │ ├── impl/ │ │ │ │ └── UserDao.java │ │ │ ├── service/ # 业务逻辑层 │ │ │ │ └── impl/ │ │ │ │ └── UserServiceImpl.java │ │ │ ├── controller/ # 控制层 (处理用户输入和菜单) │ │ │ │ └── ConsoleController.java │ │ │ ├── util/ # 工具类 (DatabaseUtil, ConsoleInputHelper等) │ │ │ └── Main.java # 程序入口 │ │ └── resources/ # 配置文件 │ └── ...

各层职责明确：

• Model层：就是普通的Java Bean，只有属性和getter/setter，对应数据库表。
• DAO层：只负责最原子的数据库CRUD操作。例如UserDao只有findById,insert,update,delete等方法。它不关心业务规则。
• Service层：包含核心业务逻辑。例如UserService的login方法，它会调用UserDao查询用户，然后验证密码，可能还会记录登录日志。事务管理通常也放在这一层。
• Controller层：负责与用户交互。在控制台项目中，它就是你的菜单控制器，接收用户输入，调用对应的Service方法，然后根据结果输出信息。

让我们以“用户登录”这个功能为例，看看重构后的代码如何组织：

1. Model层 (User.java)

public class User { private Integer userId; private String name; private String sex; private String password; private Integer role; // 1-管理员，2-教师，3-学生 // ... 省略 getters and setters }

2. DAO层 (UserDao.java接口及其实现)

public interface UserDao { User findByUsernameAndRole(String username, int role); // ... 其他CRUD方法 } public class UserDaoImpl implements UserDao { @Override public User findByUsernameAndRole(String username, int role) { String sql = "SELECT userid, name, sex, password, role FROM user WHERE name = ? AND role = ?"; try (Connection conn = DatabaseUtil.getConnection(); PreparedStatement pstmt = conn.prepareStatement(sql)) { pstmt.setString(1, username); pstmt.setInt(2, role); try (ResultSet rs = pstmt.executeQuery()) { if (rs.next()) { User user = new User(); user.setUserId(rs.getInt("userid")); user.setName(rs.getString("name")); user.setSex(rs.getString("sex")); user.setPassword(rs.getString("password")); user.setRole(rs.getInt("role")); return user; } } } catch (SQLException e) { throw new DataAccessException("查询用户失败", e); } return null; } }

3. Service层 (UserService.java)

public interface UserService { User login(String username, String password, int role); } public class UserServiceImpl implements UserService { private final UserDao userDao; public UserServiceImpl(UserDao userDao) { this.userDao = userDao; } @Override public User login(String username, String password, int role) { // 1. 参数校验 if (username == null || username.trim().isEmpty()) { throw new IllegalArgumentException("用户名不能为空"); } // 2. 调用DAO获取用户 User user = userDao.findByUsernameAndRole(username, role); // 3. 业务逻辑：验证密码 if (user != null && user.getPassword().equals(password)) { // 实际项目中应对密码进行哈希比较 return user; } // 4. 登录失败 throw new AuthenticationException("用户名、密码或角色错误"); } }

4. Controller层 (LoginController.java或集成到主控制器)

public class LoginController { private final UserService userService; private final Scanner scanner; public LoginController(UserService userService) { this.userService = userService; this.scanner = new Scanner(System.in); } public User showLoginMenu() { while (true) { System.out.println("============ 欢迎使用学生选课系统 ==========="); System.out.println("1. 管理员登录"); System.out.println("2. 教师登录"); System.out.println("3. 学生登录"); System.out.println("0. 退出系统"); System.out.print("请选择您的身份: "); int roleChoice = ConsoleInputHelper.getIntInRange("", 0, 3); if (roleChoice == 0) { System.out.println("感谢使用，再见！"); System.exit(0); } System.out.print("请输入用户名: "); String username = scanner.nextLine(); System.out.print("请输入密码: "); String password = scanner.nextLine(); // 注意：控制台输入密码是明文的，实际应用需处理 try { User loggedInUser = userService.login(username, password, roleChoice); System.out.println("登录成功！欢迎，" + loggedInUser.getName()); return loggedInUser; // 返回登录成功的用户对象 } catch (AuthenticationException e) { System.out.println("登录失败: " + e.getMessage()); System.out.println("请按任意键重试..."); scanner.nextLine(); } catch (Exception e) { System.out.println("系统错误，登录失败。"); e.printStackTrace(); // 开发阶段可打印，生产环境应记录日志 } } } }

经过这样的重构，你的代码会变得模块化、可测试、易维护。DAO可以单独测试数据库操作，Service可以模拟DAO进行业务逻辑测试，Controller只负责界面交互。当你想把控制台程序改成Web应用时，只需要替换掉Controller层，Service和DAO层几乎可以无缝复用。

最后，我想说的是，开发一个控制台选课系统，远不止是把功能跑通那么简单。从混乱的数据库连接到清晰的事务管理，从脆弱的输入处理到坚固的分层架构，每一步的优化都是你从“写代码”到“做工程”的思维跃迁。这些在小型项目中养成的良好习惯，在你未来面对更复杂的系统时，会成为你最得力的武器。别怕一开始麻烦，把这些坑一个个填平，你的代码能力和项目质量，自然会脱颖而出。