企业官网建设流程全解析

1. 为什么做这个项目：老账本式学生管理的崩溃现场

先还原一下自己的问题场景。我带过不少刚学完 Java 基础的同学，也经常被人拿着一份课程设计需求来问：能不能帮我写一个 java 学生管理系统。说实话，这种题目在高校里出现的频次极高，什么学生信息管理、学生选课管理系统、学生综合考评管理系统，换汤不换药。但真正能把这个项目讲清楚、写干净、应付得了答辩的人，并不算多。

大多数人遇到的卡点是这样的：控制台里一堆System.out.println()拼出一个菜单，把所有业务逻辑全塞进main方法里，一个switch套一个while，表面上看功能是跑通了，但你让他解释“这段代码为什么这样写”，他只能支支吾吾。更尴尬的是，一旦需求从“查一条”变成“模糊查询”“分页查询”“事务回滚”，代码就立刻失控。

我做这个项目的目标很简单：用纯 JDBC 加面向对象思想，写一个能扛住课程设计答辩、能讲清楚每一步设计理由、并且能平滑扩展的学生管理系统。不引入 MyBatis、不引入 Spring，就靠 Java 基础语法、JDBC、MySQL，把增删改查、登录、选课、统计这些核心业务完整地落地一遍。适合正在做 Java 课程设计的人，也适合想把“面向对象编程 Java”落到实处、而不是只背概念的人。

这篇文章我会把所有关键设计取舍、核心代码逻辑、坑点排查过程全部拆开讲。你跟着做完，收获的不只是一个 Demo，而是一套“以后做任何管理系统都能套用”的分层思路。

2. 破局思路：先定业务边界，再决定技术方案

2.1 需求边界：一个管理系统到底要管什么

很多同学一拿到“学生管理系统”就开始写代码，这其实是最大的坑。需求都没定清楚，写出来的系统一定到处是补丁。我建议先花半小时把业务边界理清楚，明确哪些功能必须有、哪些功能可以后加。

基础的业务闭环是这几个：

• 学生信息管理：新增、查询、修改、删除学生基本信息（学号、姓名、性别、年龄、班级等）。
• 课程信息管理：维护课程基本信息（课程编号、课程名、学分、授课教师）。
• 选课管理：学生选课、退课，每个学生可以选多门课，一门课可以被多个学生选。
• 数据统计：比如统计每门课的选课人数、某个学生的总学分。
• 系统登录：用户登录后才有权限操作系统。

把边界画清楚之后，你会发现数据表结构也跟着清晰了：至少需要三张表，加上一张用户表。为什么不是把课程信息直接塞进学生表里？这是典型的数据库设计问题，下面展开说。

2.2 数据表设计：为什么要拆出中间表

学生和课程是多对多关系，一个学生选多门课，一门课被多个学生选，这种关系在关系型数据库里必须用中间表来解除。

所以我建了四张表：

• t_user：用户表，字段为 user_id、username、password（做了 MD5 加密）、role。
• t_student：学生表，字段为 student_id（主键）、name、gender、age、class_name。
• t_course：课程表，字段为 course_id（主键）、course_name、credit、teacher。
• t_stu_course：选课关系表，字段为 id、student_id、course_id，联合唯一索引uk_student_course。

为什么要单独建t_stu_course中间表？如果我在学生表里加两个字段存“选了哪些课程”，最多也就是存储用逗号拼接的课程编号，查询时FIND_IN_SET勉强能查，但一旦要做“退一门课”“统计选课人数”，这种设计会让 SQL 变得极其难写，而且完全没法保证数据一致性。中间表的设计看似多一步，实际上是给自己的后续功能铺平了路。

建表语句我直接给出来，你可以在 MySQL 里执行：

CREATE DATABASE student_db DEFAULT CHARSET utf8mb4; USE student_db; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role VARCHAR(20) DEFAULT 'student' ); CREATE TABLE t_student ( student_id VARCHAR(20) PRIMARY KEY, name VARCHAR(50) NOT NULL, gender VARCHAR(10), age INT, class_name VARCHAR(50) ); CREATE TABLE t_course ( course_id VARCHAR(20) PRIMARY KEY, course_name VARCHAR(100) NOT NULL, credit DOUBLE, teacher VARCHAR(50) ); CREATE TABLE t_stu_course ( id INT PRIMARY KEY AUTO_INCREMENT, student_id VARCHAR(20), course_id VARCHAR(20), UNIQUE KEY uk_student_course (student_id, course_id), CONSTRAINT fk_student FOREIGN KEY (student_id) REFERENCES t_student(student_id), CONSTRAINT fk_course FOREIGN KEY (course_id) REFERENCES t_course(course_id) );

外键约束在 MySQL 中默认是支持的，前提是你建表时用的引擎是 InnoDB。如果你用的是 MyISAM，外键约束写了也不生效。这个细节在答辩时经常被问到，建议记下来。

2.3 技术选型：为什么用纯 JDBC 而不是 ORM 框架

做课程设计时，有人一上来就想用 MyBatis-Plus，理由是代码少、生成快。但我的建议恰恰相反：这个阶段用力用纯 JDBC，收获最大。原因有几个：

• 面试和答辩时，面试官更想看你对 JDBC 核心原理的理解，而不是你用 ORM 的熟练度。
• 纯 JDBC 让你逼着自己去管理连接、预编译、事务，这些是后续理解任何框架的基础。
• 框架的本质是封装 JDBC，你直接使用纯 JDBC，踩过连接泄漏、预编译的坑，以后用 MyBatis 时代码出问题了，才不至于对着堆栈一头雾水。

技术栈就定为：JDK 8+、MySQL 8.0+、MySQL Connector/J 驱动、Maven 作为构建工具。IDE 用 IDEA 就行，这块保持简单。

3. 架构分层：不要让 main 方法背负全世界

3.1 包结构设计背后的逻辑

很多初级项目的通病是：所有类都放在一个包下面，所有逻辑挤在一个类里，整个项目文件少到只有三五个。我这个项目从一开始就按分层思想组织，不是为了显得高大上，而是为了“换需求时不拆筋动骨”。

包结构如下：

com.example.stums ├── entity // 实体类：User、Student、Course、StuCourse ├── dao // 数据访问层：UserDao、StudentDao、CourseDao、StuCourseDao ├── service // 业务层：选课业务、学生管理业务 ├── controller // 控制层：菜单分发、请求路由 ├── util // 工具类：DBUtil、MD5Util └── Main // 程序入口

这里我用的是经典的三层架构思路。controller 层负责接收用户输入、展示结果，service 层负责业务规则的校验和组合，dao 层只负责和数据库打交道。每一层只依赖下一层，不跨层调用。

为什么 entity 类的代码状态要和数据库字段一一对应？因为 JDBC 的结果集一次只能读一行、一行只能映射成一个对象，实体类就是 Java 和关系模型之间的扭转台。我给 Student 类的设计是标准的 POJO：

public class Student { private String studentId; private String name; private String gender; private Integer age; private String className; public Student() { } public Student(String studentId, String name, String gender, Integer age, String className) { this.studentId = studentId; this.name = name; this.gender = gender; this.age = age; this.className = className; } // getter/setter 省略，实际开发中建议手写或使用 Lombok }

有人会问：为什么 Student 不在构造器里做参数校验？比如年龄必须大于 0、学号不能为空？我的做法是构造器只做赋值，校验放到 service 层去做，因为控制台输入的数据类型本身就可能不合法（比如用户输入了一个非数字的年龄），你需要在入口就把脏数据挡掉，而构造器的职责是“创建对象”，不是“决策业务规则”。这个区分在答辩时很加分，你可以主动讲出来。

3.2 DBUtil：连接管理里最容易栽的跟头

数据库连接的获取与释放，是所有 JDBC 项目的命门。我见过不少人直接在每次 DAO 调用时DriverManager.getConnection()，用完不关，最后数据库连接数被耗尽，系统直接瘫痪。很多没有实际跑过长时操作的人，很难意识到这个问题的严重性。

我的 DBUtil 设计成单例模式加静态代码块注册驱动，这样驱动只加载一次，每次通过 DriverManager 获取连接，同时提供一个统一的关闭资源方法。代码如下：

public class DBUtil { private static final String URL = "jdbc:mysql://localhost:3306/student_db?useSSL=false&allowPublicKeyRetrieval=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai"; private static final String USER = "root"; private static final String PASSWORD = "你的密码"; static { try { Class.forName("com.mysql.cj.jdbc.Driver"); } catch (ClassNotFoundException e) { throw new ExceptionInInitializerError("MySQL驱动加载失败"); } } private DBUtil() {} public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(ResultSet rs, Statement stmt, Connection conn) { if (rs != null) { try { rs.close(); } catch (SQLException e) { e.printStackTrace(); } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { e.printStackTrace(); } } if (conn != null) { try { conn.close(); } catch (SQLException e) { e.printStackTrace(); } } } }

有几个关键点值得你注意：

• 驱动类名com.mysql.cj.jdbc.Driver是 MySQL 8.0 的驱动路径，旧版本是com.mysql.jdbc.Driver。如果你本地装的是 MySQL 8.0 却用了旧驱动类名，会直接报ClassNotFoundException，这是最常见的运行期错误之一。
• serverTimezone=Asia/Shanghai是时区参数。MySQL 8.0 的驱动要求显式指定时区，不加的话可能遇到The server time zone value 'CST' is unrecognized这个让人懵圈的报错。
• allowPublicKeyRetrieval=true是配合 MySQL 8.0 连接时 RSA 公钥获取的一个开关，你用本地库并且未做 SSL 加密时，经常会用到。
• 关闭资源的顺序必须是ResultSet先关、Statement后关、Connection最后关。不能先关 Connection 再关 ResultSet，虽然驱动大多容忍，但规范上会存在资源未释放的风险。

3.3 单例模式的实现方式：饿汉式还是双重检查

DBUtil 构造器是 private 的，不允许外部 new，这是工具类的标准写法。但为什么要用单例？原因是工具类本身没有状态，不需要多个实例。用一个静态方法getConnection()每次返回新的 Connection 即可，这和 Spring 的单例管理思路一致。如果未来并发量上来，直接引入连接池（比如 HikariCP）替换这一段逻辑即可，DBUtil 的上层代码完全不用改。这种“接口不变、实现互换”的思维，也是分层架构的核心收益之一。

4. 核心功能实现：从登录到选课就像剥洋葱

4.1 登录与权限校验的细节处理

登录功能看似简单，其实藏着不少门道。我做的用户表里存放的是加密后的密码，而不是明文密码。MD5 算法本身已经不算安全，但作为课程设计足够演示“密码不能明文存储”这个理念。计算 MD5 的代码写成一个工具方法：

public class MD5Util { public static String md5(String source) { try { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] bytes = md.digest(source.getBytes(StandardCharsets.UTF_8)); StringBuilder sb = new StringBuilder(); for (byte b : bytes) { String hex = Integer.toHexString(b & 0xff); if (hex.length() == 1) { sb.append('0'); } sb.append(hex); } return sb.toString(); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(e); } } }

登录校验的逻辑放在 service 层，先按 username 查出用户记录，如果查不到直接返回“用户名不存在”；查到了再比对密码摘要，一致才放行。这样设计的好处是：数据库不会把密码明文暴露在 SQL 日志里，同时你可以拿“为什么用 MD5 而不是可逆加密”在答辩时展开讲解。顺带一提，真正生产环境里推荐 BCrypt 加盐，MD5 加盐也比裸 MD5 安全得多。

用户登录成功后，我会把当前用户角色存到一个静态的Session类里。为什么用静态类？对于控制台程序来说，没有 Web 容器帮你管理 Session，用一个静态变量保存登录状态是最直接的手段。生产环境里这样做有并发和线程安全问题，但课程设计阶段讲清楚这个“模拟 Session”的来龙去脉就足够了。

4.2 学生增删改查：PreparedStatement 的使用边界

学生信息管理的 DAO 层，最核心的操作就是增删改查。这里我必须强调一个原则：永远不要用 Statement 拼接 SQL，永远用 PreparedStatement。原因不光是防 SQL 注入，还有 SQL 预编译带来的性能红利。PreparedStatement 在数据库端会缓存执行计划，多次执行同样结构的 SQL 时，效率远高于 Statement 动态拼接。

以新增学生为例：

public boolean insertStudent(Student student) { String sql = "INSERT INTO t_student (student_id, name, gender, age, class_name) VALUES (?, ?, ?, ?, ?)"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, student.getStudentId()); ps.setString(2, student.getName()); ps.setString(3, student.getGender()); ps.setInt(4, student.getAge()); ps.setString(5, student.getClassName()); return ps.executeUpdate() > 0; } catch (SQLException e) { e.printStackTrace(); return false; } }

这里我用了 JDK 7 的 try-with-resources 语法，Connection、PreparedStatement 都会自动关闭，代码变得非常干净。如果你还在用老的finally手动关闭，建议改成这种写法。注意，ResultSet 在查询场景也能放进 try-with-resources 里一起自动关闭，前提是变量声明写在圆括号里。

删除操作有一点特殊：学生被删了，他关联的选课记录不能留下来变成脏数据。所以在 StudentDao 的deleteStudentById里，我先删t_stu_course中该学生的记录，再删t_student记录。这两个操作必须是一个事务，否则删到一半出错，数据库就残留了选课信息。后面我会专门讲事务怎么写。

4.3 模糊查询与分页：控制台程序也要有的功能

控制台程序虽然不需要做网页分页组件，但查询接口的数据量一大，一次性全查出来既慢又难展示。我用的是 LIMIT 分页，通过用户输入页码和每页条数来动态拼 SQL：

public List<Student> queryStudentsByPage(String keyword, int pageNum, int pageSize) { String sql = "SELECT * FROM t_student WHERE name LIKE ? OR class_name LIKE ? LIMIT ?, ?"; List<Student> list = new ArrayList<>(); try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { String likePattern = "%" + keyword + "%"; ps.setString(1, likePattern); ps.setString(2, likePattern); ps.setInt(3, (pageNum - 1) * pageSize); ps.setInt(4, pageSize); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { Student stu = new Student(); stu.setStudentId(rs.getString("student_id")); stu.setName(rs.getString("name")); stu.setGender(rs.getString("gender")); stu.setAge(rs.getInt("age")); stu.setClassName(rs.getString("class_name")); list.add(stu); } } } catch (SQLException e) { e.printStackTrace(); } return list; }

分页的参数计算容易出错。LIMIT 的第一个参数是偏移量，pageNum 从 1 开始，所以偏移量是(pageNum - 1) * pageSize。我见过很多人写成pageNum * pageSize，导致第一页丢了几条数据。这类小问题在测试时容易一不留神就放过，建议你写完后用一个数据量稍微大点的库验证一下。

4.4 选课功能与数据一致性保证

选课是业务规则最复杂的部分。学生选课要考虑一个问题：同一门课不能选两次。这个约束我在建表时用联合唯一索引UNIQUE KEY uk_student_course (student_id, course_id)保证了。当重复插入时，MySQL 会报Duplicate entry异常，DAO 层捕获这个 SQLException 后向上抛出业务异常，提示“该课程已被选择”。

核心代码如下：

public boolean selectCourse(String studentId, String courseId) { String sql = "INSERT INTO t_stu_course (student_id, course_id) VALUES (?, ?)"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, studentId); ps.setString(2, courseId); return ps.executeUpdate() > 0; } catch (SQLIntegrityConstraintViolationException e) { throw new BusinessException("该课程已经被选择，不能重复选课"); } catch (SQLException e) { throw new BusinessException("选课失败: " + e.getMessage()); } }

不要小看这个异常分类处理。如果什么都不区分，遇到外键约束失败、唯一索引冲突以及网络异常，你反馈给用户的信息会非常模糊。我用SQLIntegrityConstraintViolationException专门捕获约束类异常，这样用户能看到明确提示。这种“根据异常类型决定用户提示”的思路，在任何系统里都适用。

退课的逻辑正好相反，删除t_stu_course里的一条记录：

public boolean dropCourse(String studentId, String courseId) { String sql = "DELETE FROM t_stu_course WHERE student_id = ? AND course_id = ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, studentId); ps.setString(2, courseId); return ps.executeUpdate() > 0; } catch (SQLException e) { throw new BusinessException("退课失败: " + e.getMessage()); } }

4.5 事务处理：setAutoCommit 与回滚的实战代码

前面提到删除学生时要先删选课关系再删学生，这两个操作必须放在同一个事务里。很多同学在这个项目里没有写过事务，这是一个很大的遗憾。事务处理的标准模板是：

public boolean deleteStudentWithCourses(String studentId) { String deleteStuCourseSql = "DELETE FROM t_stu_course WHERE student_id = ?"; String deleteStudentSql = "DELETE FROM t_student WHERE student_id = ?"; Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); try (PreparedStatement ps1 = conn.prepareStatement(deleteStuCourseSql)) { ps1.setString(1, studentId); ps1.executeUpdate(); } try (PreparedStatement ps2 = conn.prepareStatement(deleteStudentSql)) { ps2.setString(1, studentId); ps2.executeUpdate(); } conn.commit(); return true; } catch (SQLException e) { if (conn != null) { try { conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } } e.printStackTrace(); return false; } finally { if (conn != null) { try { conn.setAutoCommit(true); conn.close(); } catch (SQLException e) { e.printStackTrace(); } } } }

这里有几个细节值得强调。第一，setAutoCommit(false)必须在执行任何写操作之前调用，一旦你忘了，每条 SQL 都会自动提交，事务回滚就成了空谈。第二，回滚操作必须在 catch 里做，而且如果回滚本身也抛异常，不能影响原始异常的上抛。第三，finally 里把 autoCommit 恢复为 true 是个好习惯，因为连接从池里归还时如果还处于非自动提交状态，下一个人拿到这条连接会踩大坑，这是数据一致性 bug 最常见的来源之一。

5. 我踩过的坑：排查链路还原与修复记录

5.1 驱动加载失败的完整排查过程

先还原一个真实崩溃现场。我第一次用 MySQL 8.0 跑这套代码时，启动直接报错：

java.lang.ClassNotFoundException: com.mysql.jdbc.Driver

当时第一反应是驱动包没导入，检查 pom.xml，依赖是有的。后来静下心一想，旧版驱动路径是com.mysql.jdbc.Driver，MySQL 8.0 的驱动路径换成了com.mysql.cj.jdbc.Driver。驱动路径不对，自然加载失败。这个坑非常容易踩，尤其是你从网上复制旧教程代码时。

解决的办法有两种：要么把Class.forName的参数改成新路径，要么降级用旧版驱动。我的建议是升级路径，因为旧驱动在 MySQL 8.0 下已经不被官方支持。另外我提醒一下，Maven 依赖里要写mysql-connector-java8.x 版本，5.x 版本的 jar 包里只有旧路径。

5.2 中文乱码与时区报错的修复记录

中文乱码这个问题几乎是 JDBC 项目的保留节目。症状是：数据库表结构、控制台、连接串各说各话，插入中文后变成??或????。

排查链路是这样的：

1. 先确认 MySQL 表本身是utf8mb4编码，这一步在建表时已经处理。
2. 再确认 JDBC 连接串带了characterEncoding=utf8，这样驱动在客户端和服务器之间传输时能正确解码。
3. 最后确认控制台编译环境也是 UTF-8。IDEA 项目编码设成 UTF-8 后，问题通常能解决。

时区报错的排查稍微绕一点。报错长这样：

The server time zone value 'CST' is unrecognized or represents more than one time zone.

这个不是 Java 代码的 bug，而是 MySQL 8.0 连接协议要求客户端指定时区。在连接串后加serverTimezone=Asia/Shanghai即可。这里的CST是一个大坑名，中文环境下的 MySQL 默认时区可能被解析成China Standard Time，也可能被解析成美国中部时间，含糊不清，所以驱动直接报错。指定成Asia/Shanghai后，歧义就消除了。

5.3 like 查询拼接占位符的顺序问题

模糊查询的 SQL 写法也不止一次坑人。我第一次写的时候是：

String likePattern = "%" + keyword + "%"; ps.setString(1, likePattern);

这个写法没问题。但如果我换成LIKE ?并且setString(1, keyword)时，实际效果就变成了“精确匹配包含关键字为空”的查询，结果集永远是空。原因很简单：LIKE 后面的%是 SQL 模式的一部分，不是参数值的一部分。

还有一种错误写法是把%直接拼进 SQL：

String sql = "SELECT * FROM t_student WHERE name LIKE '%" + keyword + "%'";

这种写法虽然功能上能跑，但打开了 SQL 注入的大门。你永远不应该用手工字符串拼接的方式去构造 SQL，哪怕它看起来更短。这是一个安全底线问题，给你十分钟都背不下来的概念，在面试中却是必问题。把参数和 SQL 模板分离，是这个系统里最值得养成的习惯。

5.4 ResultSet 里游标移动的误解：next() 的边界

ResultSet.next()的语义是“判断是否有下一行，如果有则把游标移到那一行”。很多人第一次写 JDBC 查询时，会写出这种代码：

if (rs.next()) { // 只处理第一行 }

如果要循环取出全部结果，必须使用while (rs.next())。还有一个细节：ResultSet的初始游标位置在第一行之前，而不是第一行。也就是说你要先调用一次next()才能拿到第一条数据。这个和数组索引从 0 开始的直觉很不一样，容易在写循环时多漏一条数据。见过一个同学在while里判断然后 break，结果第一条数据被吞掉，后面排查了很久才发现是多了一次next()。

6. 测试用例与性能细节：不要只满足于“能跑”

6.1 手动测试脚本：把边界条件都过一遍

写完代码之后，很多人就匆匆交作业了。我的习惯是准备一张测试清单，把自己当用户从头到尾操作一遍，重点覆盖边界和异常输入：

• 用户名或密码为空时，登录模块的提示是否友好。
• 不存在的用户登录，会不会抛空指针异常。
• 新增学生时填入重复学号，程序会不会崩。
• 删除一个已选课的学生，选课关系表是否被正确清理。
• 选课两次同一课程，业务提示是否准确。
• 分页查询时 pageNum 传入 0 或者负数，结果是什么。
• 数据库连接断开时，程序整体是否还能正常退出而不是卡死。

这些测试不需要写单元测试框架，用控制台手动跑一遍就行，但每一条都很关键。很多“看起来跑通了”的系统，面对这些边界条件时，实际上一推就倒。面试官或老师很多时候不看你的正常功能演示，专门挑异常时刻的操作来考察你程序的健壮性。

6.2 批处理与批量导入：体验一把真正的性能差距

如果只做增删改查，这个项目还差点意思。建议你再加一个“批量导入学生名单”的功能，把 Excel 或文本里的学生名单一次性写入数据库。这里有个性能对比值得体验：一条一条用addBatch()批量插入，和一次性循环逐条插入，两者的时间差距在小数据量时看不出来，在几千条数据时足够明显。

批量写法的核心代码：

public int batchInsertStudents(List<Student> students) { String sql = "INSERT INTO t_student (student_id, name, gender, age, class_name) VALUES (?, ?, ?, ?, ?)"; int total = 0; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { conn.setAutoCommit(false); for (Student s : students) { ps.setString(1, s.getStudentId()); ps.setString(2, s.getName()); ps.setString(3, s.getGender()); ps.setInt(4, s.getAge()); ps.setString(5, s.getClassName()); ps.addBatch(); } int[] result = ps.executeBatch(); conn.commit(); for (int count : result) { total += count; } } catch (SQLException e) { e.printStackTrace(); } return total; }

要点有两个：第一，批量操作要配合事务使用，否则中途出错时已经插入的数据不会自动回滚，会产生一堆“半成品”数据；第二，executeBatch()返回一个int[]，每个元素代表对应 SQL 语句影响的行数。你可以用它对账，确认写进去的总条数和预期一致。

为什么小数据量看不出差异？因为逐条插入时，每条 SQL 都要经历一次网络往返和一次事务提交，MySQL 的 InnoDB 引擎每次 commit 都要刷磁盘日志（fsync），这就是最大的性能瓶颈。批处理把多条 SQL 打包发送，最后只提交一次，省掉了大量重复的磁盘同步开销。这个原理在面试里也常被问到，值得你理解透。

6.3 排序相关：自己实现还是交给 SQL

热搜词里有“冒泡排序 java”，很多同学会在管理系统的练习里自己写排序算法来展示基本功。我的建议是：学生管理系统的列表展示直接使用 SQL 的ORDER BY，不需要在 Java 内存里排序。数据库索引和排序优化比你自己写的算法要高效得多。如果你真的想练手，可以写一个独立的排序测试类，用冒泡和快速排序分别对数据量不同的数组进行排序，对比时间，这是很好的基本功练习。

但不要把自行排序放到系统的主链路里。原因很简单：数据量一旦超过几万条，内存排序不仅浪费内存，还会和你自己实现的时间复杂度死磕。SQL 的ORDER BY可以借助索引直接完成，你的业务代码不需要知道底层是怎么做的。

7. 演进建议：从学生管理系统到更完整的业务体系

这个系统如果用来交课程设计，做到第六节的内容已经完全够用。但如果方向不止于此，想让它成为简历上真正能讲的项目，我建议往这几个方向扩展。

第一个方向是“学生选课管理系统”的选课业务增强。比如添加选课时间窗口、选课人数上限、退课截止时间等规则。这些业务规则一旦多起来，你就需要认真设计 service 层的职责边界了，不然所有判断逻辑都堆在 controller 里，代码会迅速腐化。

第二个方向是引入行级权限和社会角色的区分。现在用户表里已经有 role 字段，你可以扩展出管理员、教师、学生三种角色，管理员可以管理全部数据，教师只能查询自己所授课程的选课名单，学生只能维护自己的信息。这就是“行级权限 java”这类热搜词背后的核心场景：同一个接口，不同角色看到的数据范围不一样。实现方式可以在 SQL 层加条件，也可以通过 service 层做数据过滤。

第三个方向是数据一致性话题的延伸。现在选课、退课、删学生在同一个事务里完成，但“保证数据一致性”并不只是事务回滚这么简单，还涉及并发场景。比如两个学生在同一时刻选择名额只剩一的同一门课，你的程序是否会重复发放名额？解决思路有乐观锁（在数据表里加 version 字段，更新时比较版本号）和悲观锁（SELECT FOR UPDATE）。作为课程设计，你可以选择一个方案实现并写进说明文档，面试官看到这个细节会非常感兴趣。

第四个方向是汇总统计和报表导出。比如统计每门课的选课人数、每个学生的已修学分，然后把这个结果导出成 Excel 或者 Word 文档。热搜里的“java poi word 能生成图表吗”对应的就是这类需求。Apache POI 可以生成 xlsx 表格，其中单元格里可以嵌入图表并不直观，更常见的做法是生成 xlsx 数据后交给 Excel 渲染图表，或者在 Word 里用文本加表格的方式展示统计结果。这一类扩展能把系统和实际工作场景连接起来。

8. 写在最后：关于这个项目，我的一些真心话

做完这个 java 学生管理系统，最大的收获不是学会了几个 API，而是理解了“分层”和“边界”这两个词的分量。实体类是数据的边界，DAO 是 SQL 的边界，service 是业务规则的边界，controller 是用户交互的边界。每一层都守好自己的职责，系统就不会烂成一锅粥。这个道理放在任何规模的项目里都是一样的。

另外，我强烈建议你亲手把这套代码的每一步都敲一遍，而不是直接复制文中的代码块。在你敲的过程中，会遇到很多只属于你的环境问题，比如驱动版本、时区设置、控制台编码。解决这些问题的过程，才是真正提升编程能力的过程。把报错信息贴进搜索引擎时，记得加上你的 MySQL 版本和 JDK 版本，答案会更准确。

最后说一个实用技巧：代码写完提交之前，没有必要写复杂的单元测试框架，但至少要准备一个可以重复执行的 smoke test。每次改动完，跑一遍这个流程，确认登录、新增、查询、删除、选课这些基本链路没有回归。这能帮你省下大量手工点菜单的时间，也能让你在答辩演示时更加从容。项目不在大，在于你能不能把每一个设计决策讲得清清楚楚。