拓冰网站定制 
简介这是一份基于Java与Sql Server实现的图形界面学籍管理系统课程设计资源面向高校计算机专业学生完成数据库课程设计或Java课设。系统支持学生信息文本导入与手动录入、按学号或课程号修改成绩、班级增删改查、多条件查询学生及成绩详情、按学号查看任课教师、教学计划统计、开除预警自定义可设置选修/必修学分阈值以及数据库权限控制的登录登出覆盖学籍管理常见业务业务流程完整。压缩包共52个文件包含24个Java源码、5个SQL脚本建库建表、视图、存储过程、函数、用户授权、10个TXT说明与导入数据、DOCX使用说明书、可运行JAR包及开发截图与PPT整体2.55MB目录结构按源码、数据库、文档分类。通过源码和文档可掌握Swing界面设计、Sql Server数据库建模与存储过程、权限控制、批量数据处理等技能附带JAR包可直接运行体验SQL脚本可快速还原数据库适宜课程设计参考或项目二次开发。目前已有233人学习下载。1. 为什么一个老掉牙的 CRUD 课题还能让 Java 开发者翻车学籍管理系统听起来是每个 Java 课设都绕不开的“老三样”但真动手做的时候你会发现坑全在你不当回事的地方SQL Server 的驱动和连接串版本对不上、sa 账号策略把登录锁死、GUI 线程里直接跑 JDBC 导致界面卡成幻灯片。这个基于 Java SQL Server 的 GUI 学籍管理系统做的是一套桌面端的学生档案、班级、成绩维护工具核心是 Swing 界面上把 JDBC 的增删改查跑通适合正在做课设的本科生、刚接触桌面数据库开发的实习生以及想拿一个完整 Java 数据库项目练手的人。一句话说清楚价值它不教你怎么写惊艳的算法而是教会你 Java 桌面程序连 SQL Server 时那一整条链路里所有“没人明说但一定会遇到”的坑。接下来我把这套系统从选型、建库到代码落地拆开讲最后给你几条能直接抄的排查路径。2. 技术选型与系统设计为什么是 Swing 而不是 Web2.1 GUI 框架选型Swing 能活到今天是有原因的做桌面学籍管理可选的技术栈其实没有那么多。JavaFX 功能更强、样式更现代但课设和中小型内部工具的落地成本偏高AWT 太老组件外观和布局能力都跟不上Swing 的优势在于 JDK 内置、资料极多、且 JTable 这种数据密集型组件在显示数据库结果集时非常顺手。从阶段和可维护性出发Swing JDBC SQL Server 是这个标题最常见的组合它不是最潮的却是最容易跑通的一条路。关键的取舍在于不要用 SWT。SWT 底层走 native 控件Windows 上性能好但打包分发时会牵扯一堆平台相关的 dll换台机器跑不起来是常事。Swing 是一个听话的孩子你在哪写的换台机器 JVM 一装照样跑。接口风格上这个系统通常采用单窗口多面板的设计。左侧是导航树中间是 JTable下方是操作按钮区弹窗做新增/编辑表单。这种“主从结构”对学籍管理来说够用了学生主表、班级表、成绩表三张表就能把主干业务撑起来。2.2 系统模块拆解先分模块再写代码别上来就 new JFrame学籍管理系统的模块划分我一般建议按数据域切而不是按页面切。按页面切会出现“学生信息页里要写成绩成绩页里又要查学生”这种代码耦合。按数据域切的话落地下来大概是这样一个结构模块核心数据表主要功能学生信息维护Student新增、编辑、删除、按学号/姓名检索班级管理Class班级信息维护、学生按班统计成绩管理Score录入成绩、按课程查询、成绩区间过滤系统管理User登录账号、修改密码、操作日志模块表先定下来再去建工程目录。包名我喜欢按com.xxx.ms为根下面拆ui、db、dao、model、util五个包。ui 里只放 JFrame、JPanel、JTable 相关的类dao 里只写 JDBC 语句model 里是纯 POJO。这个分层在项目规模小的时候看起来“多此一举”但你后面要加导出 Excel 或做图表统计时会感谢当初的自己。2.3 数据库连接的两种主流方案JDBC 直连与连接池的取舍对于这种桌面端系统连接池比如 HikariCP、Druid反而是可以不用考虑的。桌面应用的并发量极低通常就是单机几个人用每次操作开一个 Connection、用完 close 掉是完全没有问题的。引入连接池会带来配置复杂度比如连接池线程被 GUI 线程阻塞后还容易出现“界面点一下就没反应”的错觉。场面话是“性能更好”实际做下来是给自己增加排查负担。我的建议很明确桌面 GUI 管理端场景下JDBC 直连 每次操作自动关闭连接是更可靠的落地路径。真正该优化的不是连接复用而是 SQL 语句本身。所以整个系统的数据访问层只需要一个工具类加载驱动、获取连接、关闭资源三个方法就够。下面的代码是可以直接抄进 util 包的写法import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; public class DBUtil { // 按你自己的实例名和库名改localhost\SQLEXPRESS 是 SQL Server Express 的默认实例名 private static final String URL jdbc:sqlserver://localhost:1433;databaseNameStudentMS;encryptfalse; private static final String USER sa; private static final String PASSWORD 123456; static { try { // SQL Server 专用驱动类jtds 之类的第三方驱动不要和它混用 Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver); } catch (ClassNotFoundException e) { e.printStackTrace(); } } 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(); } } } }注意几个参数databaseNameStudentMS库名必须和你实际建的库一致encryptfalse这个参数在 SQL Server 2019 以上必须显式关闭加密否则 JDBC 驱动默认要求加密连接而 SQL Server 默认不开启证书直接给你抛 SSL 相关异常。端口 1433 是 SQL Server 默认实例的端口如果装的是命名实例或者改过端口这里也要对应改。连接串里还有个常见选项loginTimeout5可以加在连接串尾部比如;loginTimeout5。它的作用是控制登录超时秒数避免数据库服务没起来时你的程序卡在连接上十几秒才报错。3. 环境准备与数据库建模SQL Server 连不上的坑都在前半小时3.1 SQL Server 安装与账号策略从 sa 登录失败的细节说起这个项目用 SQL Server 而不是 MySQL一个很重要的原因是标题明确指了方向另一个是 SQL Server 在 Windows 桌面端的安装和管理确实比 MySQL 更“省心”。但省心不等于没坑最典型的就是 sa 账号登录问题。SQL Server 默认安装时是 Windows 身份验证模式你 JDBC 里写usersa绝对登录不进去。解决办法分两步。第一步用 Windows 身份验证登录 SSMS右键服务器属性在“安全性”里选“SQL Server 和 Windows 身份验证模式”。第二步在安全性 - 登录名 - sa 的属性里设置密码并启用登录。这里特别注意 SQL Server 2012 之后的密码策略默认是强制实施的密码复杂度不够直接报错而且密码有效期到了之后sa 登录会报“密码已过期”的 18488 错误需要在 SSMS 里勾上“下次登录时更改密码”或者在 SQL 里执行ALTER LOGIN sa WITH CHECK_POLICY OFF;来解除策略限制。做完这些还要检查 TCP/IP 协议是否启用。打开“SQL Server 配置管理器”找到“SQL Server 网络配置”确保 TCP/IP 状态是“已启用”。这一步不做的话你在本机用 SSMS 能连上但 Java 程序用jdbc:sqlserver://localhost:1433就是连不通因为 JDBC 走的是 TCP 协议而 SSMS 可以走共享内存协议。这类问题报错信息也是千奇百怪绝大多数是“Connection refused”或者“Connection reset”看着像网络问题实际上协议没开。3.2 建库建表三张表把学籍主流程跑起来数据库设计不需要搞得很复杂学籍管理的核心数据域是学生、班级、成绩这三板斧。设计时我把班级独立成表而不是在学生表里存className是为了后续调整班级名时不用批量更新学生记录。成绩表用联合主键student_id course_id这样从数据库层面就能挡住同一个人同一门课录两次成绩的脏数据。还有一个细节学号的唯一性约束必加。学号一旦重复后面所有按学号做的关联查询都会出现一对多的错误结果而且这种错误不会抛异常只会在界面上显示重复行非常难排查。下面是我实际使用过的建表脚本SQL Server 环境下可直接执行CREATE DATABASE StudentMS; GO USE StudentMS; GO CREATE TABLE Class ( class_id INT IDENTITY(1,1) PRIMARY KEY, class_name NVARCHAR(50) NOT NULL UNIQUE, grade_year INT NOT NULL ); CREATE TABLE Student ( student_id NVARCHAR(20) PRIMARY KEY, -- 学号用字符串不用整型前面可能有0 student_name NVARCHAR(50) NOT NULL, gender NCHAR(1) CHECK (gender IN (男, 女)), birth_date DATE, class_id INT NULL, phone NVARCHAR(20), CONSTRAINT FK_Student_Class FOREIGN KEY (class_id) REFERENCES Class(class_id) ); CREATE TABLE Score ( student_id NVARCHAR(20) NOT NULL, course_id NVARCHAR(20) NOT NULL, course_name NVARCHAR(50) NOT NULL, score DECIMAL(5,2) CHECK (score BETWEEN 0 AND 100), exam_date DATE, PRIMARY KEY (student_id, course_id), CONSTRAINT FK_Score_Student FOREIGN KEY (student_id) REFERENCES Student(student_id) );几个容易被新手误解的点NVARCHAR是 SQL Server 中存储 Unicode 字符的类型处理中文姓名和课程名时用的是它而不是VARCHAR。如果你建表用了VARCHAR连接串里没加characterEncoding什么的话中文存储和读取时大概率出现乱码。学号字段也就是student_id我特意定义成了NVARCHAR(20)哪怕学号里全是数字也不建议用INT或BIGINT因为很多学校的学号带前导零整型一存就把 0 吞了。另外表结构里这三个CREATE TABLE有先后依赖Class 先建Student 后建Score 最后建。因为外键引用关系摆在那里顺序反了会直接报“引用了无效的表”。如果你看到的项目里建表脚本顺序和这个不太一样那八成是表结构做了调整不影响整体理解。3.3 初始化数据没有数据你怎么调试界面建完表第一件事是灌几条测试数据不然 JTable 空空如也你连表格渲染对不对都看不出来。写一条 SQL 只插一组测试数据太麻烦我一般在 SSMS 里用循环或者多条 INSERT 批量灌。批量插入学生数据时用INSERT INTO ... VALUES一次写多行会比逐条执行快得多。SQL Server 支持在一条 INSERT 语句后面跟多个 VALUES 子句这是很多人没用过的省事写法INSERT INTO Class (class_name, grade_year) VALUES (计算机2201, 2022), (计算机2202, 2022), (软件2201, 2022); INSERT INTO Student (student_id, student_name, gender, birth_date, class_id, phone) VALUES (2022010101, 张伟, 男, 2004-03-15, 1, 13800138001), (2022010102, 李娜, 女, 2003-11-02, 1, 13800138002), (2022010201, 王强, 男, 2004-05-20, 2, 13800138003); INSERT INTO Score (student_id, course_id, course_name, score, exam_date) VALUES (2022010101, C001, Java程序设计, 87.5, 2023-06-20), (2022010102, C001, Java程序设计, 92.0, 2023-06-20), (2022010201, C002, 数据库原理, 78.0, 2023-06-22);这里的一个细节是class_id的值。如果你在执行插入之前 Class 表里已经有数据了那class_id不一定是从 1 开始的。IDENTITY(1,1)表示自增种子是 1步长是 1但如果之前有人插入过数据又删掉了自增值不会回退。所以我在写测试数据前一般先SELECT * FROM Class;确认真实的 id。不然插进去的学生会被挂到错误的班级上后面联查出来的数据就会出现“计算机2201班的学生出现在软件2201班”的怪象。如果你不想先查再插也可以用子查询来动态取 class_id不过作为初始化数据可读性差一点反而不好排查问题。测试数据建议每种情况都来一条正常数据、边界分数0 分和 100 分、空手机号。这样的数据集能帮你尽早发现界面展示时空值处理的 bug。4. CRUD 落地从登录到学生信息维护的完整链路4.1 登录功能的正确的打开方式校验写在哪一层很多课设的登录做法是界面层拿到用户名密码后比对本地写死的数组或者直接拼接 SQL 查询这些做法我都不推荐。正确的思路很简单界面上只负责收集输入鉴权的逻辑下沉到 DAO 层通过参数化查询去数据库的 User 表里查。从数据库设计层面User 表不是业务表不需要搞太复杂字段就是user_id,username,password三个。密码字段的存储讲究一点的话可以存 MD5 或 SHA-256 的哈希值但要注意 Java 里算出来的哈希要转成十六进制字符串再存进数据库直接存字节数组会出现字符集问题。对于课设和内部工具明文密码虽然不推荐但也不至于罪大恶极只是你一定要给后来接手的人留一句注释提醒这是一笔技术债。实际的登录校验代码长这样核心就是PreparedStatement的参数绑定禁止用字符串拼接public User login(String username, String password) { String sql SELECT user_id, username, password FROM [User] WHERE username ? AND password ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, password); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { User u new User(); u.setUserId(rs.getInt(user_id)); u.setUsername(rs.getString(username)); u.setPassword(rs.getString(password)); return u; } } } catch (SQLException e) { e.printStackTrace(); } return null; }注意 SQL 里[User]带了方括号。因为USER是 SQL Server 的系统保留字不加方括号这条 SQL 直接报语法错误这是 SQL Server 和其他数据库不太一样的地方。PreparedStatement的参数用?占位ps.setString(1, ...)从 1 开始计数和 JDBC 的惯例一致不要想当然从 0 开始。登录界面拿到null就弹窗提示“用户名或密码错误”拿到 User 对象就dispose()当前窗口并打开主窗体。密码错误时最好不要区分“用户不存在”和“密码错误”直接给同一个提示免得被人枚举出哪些账号存在。4.2 学生信息列表JTable 绑定 ResultSet 的最小实现列表展示在学籍管理系统里是大头。JTable 的数据模型是TableModel最简单的是把数据库查出来的 List 转成二维数组再塞给DefaultTableModel。这个方式数据量小的时候完全够用。具体做法是先查 Student 表并关联 Class 表拿到班级名称然后把每行数据的字段抽出来放进Object[]。这里有个小设计表格里展示班级名称让用户看得懂但修改时提交的是class_id这样就避免了用户看到一串数字不知所云的问题。以下是 DAO 层查询所用 SQL注意LEFT JOIN而不是INNER JOIN。为什么因为有的学生可能还没分班class_id 是 NULLINNER JOIN会把这类学生丢掉界面上就看少人了而LEFT JOIN会保留学生记录班级名显示 NULL。SELECT s.student_id, s.student_name, s.gender, s.birth_date, c.class_name, s.phone FROM Student s LEFT JOIN Class c ON s.class_id c.class_id ORDER BY s.student_id;ORDER BY s.student_id在这里很重要。如果不排序SQL Server 返回行的顺序是不保证的这次运行按学号排下次可能按物理存储顺序排。用户会看到表格里的行顺序抖来抖去第一反应是“程序出 bug 了”。这其实是数据层的玄学但加个 ORDER BY 就能治。4.3 新增与编辑表单校验是写在 GUI 层还是 DAO 层新增和编辑弹窗可以共用一个表单。我的习惯是做一个StudentDialog构造时传入一个 Student 对象传了就是编辑模式没传就是新增模式。这样能省掉一半重复代码也不容易出现两套表单字段不一致的问题。表单校验我分两层写。GUI 层做必填项和非空校验比如学号、姓名不能为空性别必须在下拉框选一个DAO 层做业务校验比如学号是否重复。这两层的职责不要搞混GUI 层的校验目的是提升交互体验DAO 层的校验目的是保证数据完整性。如果只在 GUI 层校验那绕过界面直连数据库的调用就把脏数据写进去了如果只在 DAO 层校验用户的错误输入会变成“操作失败请重试”这种莫名其妙的提示。新增学生时学号重复的处理是重点。下面这段代码通过SELECT COUNT(*)来预检查虽然存在并发间隙但在桌面单机场景下完全够用public boolean insertStudent(Student s) { String checkSql SELECT COUNT(*) FROM Student WHERE student_id ?; String insertSql INSERT INTO Student (student_id, student_name, gender, birth_date, class_id, phone) VALUES (?, ?, ?, ?, ?, ?); try (Connection conn DBUtil.getConnection(); PreparedStatement checkPs conn.prepareStatement(checkSql)) { checkPs.setString(1, s.getStudentId()); try (ResultSet rs checkPs.executeQuery()) { rs.next(); if (rs.getInt(1) 0) { return false; // 学号已存在返回 false 由界面层提示 } } try (PreparedStatement insertPs conn.prepareStatement(insertSql)) { insertPs.setString(1, s.getStudentId()); insertPs.setString(2, s.getStudentName()); insertPs.setString(3, s.getGender()); insertPs.setDate(4, s.getBirthDate() null ? null : new java.sql.Date(s.getBirthDate().getTime())); insertPs.setInt(5, s.getClassId()); insertPs.setString(6, s.getPhone()); return insertPs.executeUpdate() 1; } } catch (SQLException e) { e.printStackTrace(); return false; } }这里有几个容易翻车的细节。java.sql.Date是java.util.Date的子类但两者在 JDBC 中不能直接混用ps.setDate接受的是java.sql.Date。如果你从日期选择器拿到的是java.util.Date要手动转一下。birth_date为 NULL 时setDate(4, null)是安全的不必额外处理。class_id如果用户没选班级表单传 0 还是 -1 都行但一定不要传默认的 0 进数据库因为 Class 表里大概率没有 id0 的记录外键约束直接拒绝这条插入。4.4 成绩录入与级联删除事务和约束的边界成绩表的录入相对简单一条 INSERT 搞定。但有一个点值得认真讨论删除学生时要不要连他的成绩一起删除。如果学生退学了他的档案和成绩留在库里会导致统计出错如果直接硬删 Student 记录Score 表的外键约束会报错删除失败。我的选择是在主界面上提供“删除学生”按钮弹出确认框提示“将同时删除该生所有成绩记录”然后用一个事务把两个操作包起来。事务的意义在于如果删除成绩成功但删除学生失败数据库不会停留在“成绩没了但学生还在”的中间状态。public boolean deleteStudent(String studentId) { String deleteScoreSql DELETE FROM Score WHERE student_id ?; String deleteStudentSql DELETE FROM Student WHERE student_id ?; try (Connection conn DBUtil.getConnection()) { conn.setAutoCommit(false); try (PreparedStatement ps1 conn.prepareStatement(deleteScoreSql); PreparedStatement ps2 conn.prepareStatement(deleteStudentSql)) { ps1.setString(1, studentId); ps1.executeUpdate(); ps2.setString(1, studentId); int rows ps2.executeUpdate(); conn.commit(); return rows 1; } catch (SQLException e) { conn.rollback(); throw e; } } catch (SQLException e) { e.printStackTrace(); return false; } }事务开启的关键是conn.setAutoCommit(false)。不关掉自动提交的话第一条 DELETE 执行完就立刻提交了后续操作失败也悔之晚矣。rollback()是后悔药但前提是你在异常分支里调了它并且连接没有被提前关闭。这个代码里 try-with-resources 的嵌套结构保证了连接复用和异常回滚路径都正确。另外一个很多人忽略的细节conn.rollback()之后没有重新setAutoCommit(true)。虽然马上连接会关闭但在连接池场景下连接状态会被污染。这里直连不用连接池影响不大但如果你以后把这段代码搬到 Web 项目里记得在 finally 里恢复自动提交。5. 避坑指南从百度和搜索引擎里真心搜不到的问题记录5.1 连接 SQL Server 报错TCP 连接被强行终止现象Java 程序启动时连接数据库控制台抛The TCP/IP connection to the host localhost, port 1433 has failed而本机 SSMS 却连得好好的一点问题没有。原因这条报错九成是 SQL Server 的 TCP/IP 协议没启用SSMS 走的是共享内存或命名管道所以不受影响。剩下一成才是防火墙拦截了 1433 端口。解决打开 SQL Server 配置管理器 - SQL Server 网络配置 - 实例名的协议右键 TCP/IP 选择启用然后重启 SQL Server 服务。如果确定协议已启用再去 Windows 防火墙入站规则里放行 1433 端口。重启服务这个动作千万不能省只改配置不重启配置不会生效这是很多人忽略的“改了没用”的原因。5.2 连接串没加 encryptfalse驱动直接要求 SSL现象SQL Server 2019 以后Java 程序连接时报The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption程序完全起不来。原因新版微软 JDBC 驱动9.x 以上默认encrypttrue而 SQL Server 默认没有安装证书两者碰一起就强制握手失败。这属于新驱动与旧库的兼容性问题。解决在 JDBC URL 末尾加上;encryptfalse。如果你的 SQL Server 版本较旧不加可能也能跑但加了不会有什么坏事所以我建议不管怎样都加上。如果公司安全策略不允许明文传输那就不能简单关了事你得去 SQL Server 里配置证书后把encrypttrue保留并加上trustServerCertificatetrue绕过客户端对证书链的校验。5.3 中文乱码的根源在 NVARCHAR 而不是 Java 编码现象界面表格里中文显示正常但数据库里看到的是乱码或者反过来数据库里正常界面上是问号。原因SQL Server 的排序规则Collation默认可能是Chinese_PRC_CI_AS配合VARCHAR存储中文时走的是数据库代码页JDBC 读写时编码转换不对就会出乱码。绝大多数情况下乱码不是 Java 文件编码的问题而是建表时用了VARCHAR而不是NVARCHAR。解决把所有可能存中文的字段统一改成NVARCHAR。这是一个从建表层面就一劳永逸的解法。如果表已经建好了用ALTER TABLE Student ALTER COLUMN student_name NVARCHAR(50);把列类型改掉。就算你 Java 代码里文件编码完全正确也要先确认数据库这侧的类型是NVARCHAR才谈得上排查后续。5.4 界面卡死是 GUI 线程里跑 SQL 的必然结果现象点击“查询”按钮后如果数据量一大整个窗口就变成“白板”拖动窗口也没反应过好几秒才恢复。原因Swing 是单线程模型所有界面渲染和事件处理都在 EDTEvent Dispatch Thread上执行。你在按钮的 ActionListener 里直接跑 JDBC 查询数据库响应慢一点EDT 就被阻塞了界面整个冻结。这不是死锁是线程模型决定的“卡死”假象。解决把数据库操作丢到后台线程去执行。最简做法是new Thread(() - { ... }).start()或者用SwingWorkerT, V。查询完成后通过SwingUtilities.invokeLater()回到 EDT 更新界面。这个改动对所有查询、删除、导入功能都适用它不会让程序跑得更快但会让界面看起来“活”着用户体验是完全不同的。SwingWorkerVoid, Object worker new SwingWorkerVoid, Object() { Override protected Void doInBackground() throws Exception { ListStudent list studentDao.searchStudents(keyword); SwingUtilities.invokeLater(() - { DefaultTableModel model (DefaultTableModel) table.getModel(); model.setRowCount(0); for (Student s : list) { model.addRow(new Object[]{s.getStudentId(), s.getStudentName(), s.getGender(), s.getClassId()}); } }); return null; } }; worker.execute();5.5 SQL Server 写入性能异常别忽视 WRITELOG 等待现象批量导入几百条学生记录时SQL Server 偶尔出现写入极慢的窗口期看起来像程序卡死。原因SQL Server 的日志写入是串行化的如果有一个大事务一直没提交后续的小事务在等待写日志时会出现WRITELOG类型的等待。说直白点就是“日志写盘排队了”。这在桌面系统里少见但批量导入、一次性删大量数据时容易触发。解决批量操作时不要在一个事务里塞几千条记录。SQL Server 的日志写入模型决定了长事务对并发性能非常不友好。把批量新增拆成每 100 条提交一次能看到立竿见影的效果。另外确认数据库文件的autogrowth设置不是按“百分比”增长而是按固定 MB 增长避免文件扩容时的等待。6. 更进一步让学籍系统从“能跑”变成“好用”到这一步系统的增删改查已经完整了但距离“能交付给别人用”还差几件事。第一件是操作日志。学籍数据属于敏感数据谁在什么时间改了哪个学生的信息如果完全没有记录出了问题只能干瞪眼。加一张OperationLog表字段是log_id,user_id,action,target,log_time在 DAO 层每个修改操作后面补一条 INSERT 即可。工作量不大但对系统的可信度提升是质的飞跃。第二件是数据校验再往前一步。现在只在录入时做了基础校验但成绩表的场景里同一个人同一门课的成绩应该只允许录入一次这一点我在数据库设计时用联合主键已经挡了一刀。更细的校验是转班操作时要校验目标班级是否存在这个用前端下拉列表已经解决了大半。第三件是导出功能。JTable 的数据可以一键导出 CSV用FileWriter写文本文件就行不需要引入 POI 那套重型依赖。最后一件事也是最容易踩的坑数据库备份。你做了半天的数据没有备份等于随时归零。用 SQL Server 的BACKUP DATABASE StudentMS TO DISK D:\backup\StudentMS.bak;定期做一次完整备份比任何代码优化都有价值。我自己就经历过一次硬盘坏道导致数据库文件损坏的事故那种绝望不希望你也体验一次。从那以后我的习惯是每次交付前除了导出一份数据库脚本留底再导出一份 bak 备份文件。这是最简单的后悔药。学籍管理系统的核心价值不在功能有多花哨而在于数据经手环节的每一步都可靠可追溯。把上述四点逐项做完这个项目从“课设”到“能拿去给教务科试运行”的差距就只剩时间了。希望我的这些血泪经验帮你在做系统时少走几段弯路早点把时间花在真正有增量的功能上。本文还有配套的精品资源点击获取 Java Swing+SQL Server学籍管理系统：JDBC CRUD实战与避坑指南
简介这是一份基于Java与Sql Server实现的图形界面学籍管理系统课程设计资源面向高校计算机专业学生完成数据库课程设计或Java课设。系统支持学生信息文本导入与手动录入、按学号或课程号修改成绩、班级增删改查、多条件查询学生及成绩详情、按学号查看任课教师、教学计划统计、开除预警自定义可设置选修/必修学分阈值以及数据库权限控制的登录登出覆盖学籍管理常见业务业务流程完整。压缩包共52个文件包含24个Java源码、5个SQL脚本建库建表、视图、存储过程、函数、用户授权、10个TXT说明与导入数据、DOCX使用说明书、可运行JAR包及开发截图与PPT整体2.55MB目录结构按源码、数据库、文档分类。通过源码和文档可掌握Swing界面设计、Sql Server数据库建模与存储过程、权限控制、批量数据处理等技能附带JAR包可直接运行体验SQL脚本可快速还原数据库适宜课程设计参考或项目二次开发。目前已有233人学习下载。1. 为什么一个老掉牙的 CRUD 课题还能让 Java 开发者翻车学籍管理系统听起来是每个 Java 课设都绕不开的“老三样”但真动手做的时候你会发现坑全在你不当回事的地方SQL Server 的驱动和连接串版本对不上、sa 账号策略把登录锁死、GUI 线程里直接跑 JDBC 导致界面卡成幻灯片。这个基于 Java SQL Server 的 GUI 学籍管理系统做的是一套桌面端的学生档案、班级、成绩维护工具核心是 Swing 界面上把 JDBC 的增删改查跑通适合正在做课设的本科生、刚接触桌面数据库开发的实习生以及想拿一个完整 Java 数据库项目练手的人。一句话说清楚价值它不教你怎么写惊艳的算法而是教会你 Java 桌面程序连 SQL Server 时那一整条链路里所有“没人明说但一定会遇到”的坑。接下来我把这套系统从选型、建库到代码落地拆开讲最后给你几条能直接抄的排查路径。2. 技术选型与系统设计为什么是 Swing 而不是 Web2.1 GUI 框架选型Swing 能活到今天是有原因的做桌面学籍管理可选的技术栈其实没有那么多。JavaFX 功能更强、样式更现代但课设和中小型内部工具的落地成本偏高AWT 太老组件外观和布局能力都跟不上Swing 的优势在于 JDK 内置、资料极多、且 JTable 这种数据密集型组件在显示数据库结果集时非常顺手。从阶段和可维护性出发Swing JDBC SQL Server 是这个标题最常见的组合它不是最潮的却是最容易跑通的一条路。关键的取舍在于不要用 SWT。SWT 底层走 native 控件Windows 上性能好但打包分发时会牵扯一堆平台相关的 dll换台机器跑不起来是常事。Swing 是一个听话的孩子你在哪写的换台机器 JVM 一装照样跑。接口风格上这个系统通常采用单窗口多面板的设计。左侧是导航树中间是 JTable下方是操作按钮区弹窗做新增/编辑表单。这种“主从结构”对学籍管理来说够用了学生主表、班级表、成绩表三张表就能把主干业务撑起来。2.2 系统模块拆解先分模块再写代码别上来就 new JFrame学籍管理系统的模块划分我一般建议按数据域切而不是按页面切。按页面切会出现“学生信息页里要写成绩成绩页里又要查学生”这种代码耦合。按数据域切的话落地下来大概是这样一个结构模块核心数据表主要功能学生信息维护Student新增、编辑、删除、按学号/姓名检索班级管理Class班级信息维护、学生按班统计成绩管理Score录入成绩、按课程查询、成绩区间过滤系统管理User登录账号、修改密码、操作日志模块表先定下来再去建工程目录。包名我喜欢按com.xxx.ms为根下面拆ui、db、dao、model、util五个包。ui 里只放 JFrame、JPanel、JTable 相关的类dao 里只写 JDBC 语句model 里是纯 POJO。这个分层在项目规模小的时候看起来“多此一举”但你后面要加导出 Excel 或做图表统计时会感谢当初的自己。2.3 数据库连接的两种主流方案JDBC 直连与连接池的取舍对于这种桌面端系统连接池比如 HikariCP、Druid反而是可以不用考虑的。桌面应用的并发量极低通常就是单机几个人用每次操作开一个 Connection、用完 close 掉是完全没有问题的。引入连接池会带来配置复杂度比如连接池线程被 GUI 线程阻塞后还容易出现“界面点一下就没反应”的错觉。场面话是“性能更好”实际做下来是给自己增加排查负担。我的建议很明确桌面 GUI 管理端场景下JDBC 直连 每次操作自动关闭连接是更可靠的落地路径。真正该优化的不是连接复用而是 SQL 语句本身。所以整个系统的数据访问层只需要一个工具类加载驱动、获取连接、关闭资源三个方法就够。下面的代码是可以直接抄进 util 包的写法import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; public class DBUtil { // 按你自己的实例名和库名改localhost\SQLEXPRESS 是 SQL Server Express 的默认实例名 private static final String URL jdbc:sqlserver://localhost:1433;databaseNameStudentMS;encryptfalse; private static final String USER sa; private static final String PASSWORD 123456; static { try { // SQL Server 专用驱动类jtds 之类的第三方驱动不要和它混用 Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver); } catch (ClassNotFoundException e) { e.printStackTrace(); } } 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(); } } } }注意几个参数databaseNameStudentMS库名必须和你实际建的库一致encryptfalse这个参数在 SQL Server 2019 以上必须显式关闭加密否则 JDBC 驱动默认要求加密连接而 SQL Server 默认不开启证书直接给你抛 SSL 相关异常。端口 1433 是 SQL Server 默认实例的端口如果装的是命名实例或者改过端口这里也要对应改。连接串里还有个常见选项loginTimeout5可以加在连接串尾部比如;loginTimeout5。它的作用是控制登录超时秒数避免数据库服务没起来时你的程序卡在连接上十几秒才报错。3. 环境准备与数据库建模SQL Server 连不上的坑都在前半小时3.1 SQL Server 安装与账号策略从 sa 登录失败的细节说起这个项目用 SQL Server 而不是 MySQL一个很重要的原因是标题明确指了方向另一个是 SQL Server 在 Windows 桌面端的安装和管理确实比 MySQL 更“省心”。但省心不等于没坑最典型的就是 sa 账号登录问题。SQL Server 默认安装时是 Windows 身份验证模式你 JDBC 里写usersa绝对登录不进去。解决办法分两步。第一步用 Windows 身份验证登录 SSMS右键服务器属性在“安全性”里选“SQL Server 和 Windows 身份验证模式”。第二步在安全性 - 登录名 - sa 的属性里设置密码并启用登录。这里特别注意 SQL Server 2012 之后的密码策略默认是强制实施的密码复杂度不够直接报错而且密码有效期到了之后sa 登录会报“密码已过期”的 18488 错误需要在 SSMS 里勾上“下次登录时更改密码”或者在 SQL 里执行ALTER LOGIN sa WITH CHECK_POLICY OFF;来解除策略限制。做完这些还要检查 TCP/IP 协议是否启用。打开“SQL Server 配置管理器”找到“SQL Server 网络配置”确保 TCP/IP 状态是“已启用”。这一步不做的话你在本机用 SSMS 能连上但 Java 程序用jdbc:sqlserver://localhost:1433就是连不通因为 JDBC 走的是 TCP 协议而 SSMS 可以走共享内存协议。这类问题报错信息也是千奇百怪绝大多数是“Connection refused”或者“Connection reset”看着像网络问题实际上协议没开。3.2 建库建表三张表把学籍主流程跑起来数据库设计不需要搞得很复杂学籍管理的核心数据域是学生、班级、成绩这三板斧。设计时我把班级独立成表而不是在学生表里存className是为了后续调整班级名时不用批量更新学生记录。成绩表用联合主键student_id course_id这样从数据库层面就能挡住同一个人同一门课录两次成绩的脏数据。还有一个细节学号的唯一性约束必加。学号一旦重复后面所有按学号做的关联查询都会出现一对多的错误结果而且这种错误不会抛异常只会在界面上显示重复行非常难排查。下面是我实际使用过的建表脚本SQL Server 环境下可直接执行CREATE DATABASE StudentMS; GO USE StudentMS; GO CREATE TABLE Class ( class_id INT IDENTITY(1,1) PRIMARY KEY, class_name NVARCHAR(50) NOT NULL UNIQUE, grade_year INT NOT NULL ); CREATE TABLE Student ( student_id NVARCHAR(20) PRIMARY KEY, -- 学号用字符串不用整型前面可能有0 student_name NVARCHAR(50) NOT NULL, gender NCHAR(1) CHECK (gender IN (男, 女)), birth_date DATE, class_id INT NULL, phone NVARCHAR(20), CONSTRAINT FK_Student_Class FOREIGN KEY (class_id) REFERENCES Class(class_id) ); CREATE TABLE Score ( student_id NVARCHAR(20) NOT NULL, course_id NVARCHAR(20) NOT NULL, course_name NVARCHAR(50) NOT NULL, score DECIMAL(5,2) CHECK (score BETWEEN 0 AND 100), exam_date DATE, PRIMARY KEY (student_id, course_id), CONSTRAINT FK_Score_Student FOREIGN KEY (student_id) REFERENCES Student(student_id) );几个容易被新手误解的点NVARCHAR是 SQL Server 中存储 Unicode 字符的类型处理中文姓名和课程名时用的是它而不是VARCHAR。如果你建表用了VARCHAR连接串里没加characterEncoding什么的话中文存储和读取时大概率出现乱码。学号字段也就是student_id我特意定义成了NVARCHAR(20)哪怕学号里全是数字也不建议用INT或BIGINT因为很多学校的学号带前导零整型一存就把 0 吞了。另外表结构里这三个CREATE TABLE有先后依赖Class 先建Student 后建Score 最后建。因为外键引用关系摆在那里顺序反了会直接报“引用了无效的表”。如果你看到的项目里建表脚本顺序和这个不太一样那八成是表结构做了调整不影响整体理解。3.3 初始化数据没有数据你怎么调试界面建完表第一件事是灌几条测试数据不然 JTable 空空如也你连表格渲染对不对都看不出来。写一条 SQL 只插一组测试数据太麻烦我一般在 SSMS 里用循环或者多条 INSERT 批量灌。批量插入学生数据时用INSERT INTO ... VALUES一次写多行会比逐条执行快得多。SQL Server 支持在一条 INSERT 语句后面跟多个 VALUES 子句这是很多人没用过的省事写法INSERT INTO Class (class_name, grade_year) VALUES (计算机2201, 2022), (计算机2202, 2022), (软件2201, 2022); INSERT INTO Student (student_id, student_name, gender, birth_date, class_id, phone) VALUES (2022010101, 张伟, 男, 2004-03-15, 1, 13800138001), (2022010102, 李娜, 女, 2003-11-02, 1, 13800138002), (2022010201, 王强, 男, 2004-05-20, 2, 13800138003); INSERT INTO Score (student_id, course_id, course_name, score, exam_date) VALUES (2022010101, C001, Java程序设计, 87.5, 2023-06-20), (2022010102, C001, Java程序设计, 92.0, 2023-06-20), (2022010201, C002, 数据库原理, 78.0, 2023-06-22);这里的一个细节是class_id的值。如果你在执行插入之前 Class 表里已经有数据了那class_id不一定是从 1 开始的。IDENTITY(1,1)表示自增种子是 1步长是 1但如果之前有人插入过数据又删掉了自增值不会回退。所以我在写测试数据前一般先SELECT * FROM Class;确认真实的 id。不然插进去的学生会被挂到错误的班级上后面联查出来的数据就会出现“计算机2201班的学生出现在软件2201班”的怪象。如果你不想先查再插也可以用子查询来动态取 class_id不过作为初始化数据可读性差一点反而不好排查问题。测试数据建议每种情况都来一条正常数据、边界分数0 分和 100 分、空手机号。这样的数据集能帮你尽早发现界面展示时空值处理的 bug。4. CRUD 落地从登录到学生信息维护的完整链路4.1 登录功能的正确的打开方式校验写在哪一层很多课设的登录做法是界面层拿到用户名密码后比对本地写死的数组或者直接拼接 SQL 查询这些做法我都不推荐。正确的思路很简单界面上只负责收集输入鉴权的逻辑下沉到 DAO 层通过参数化查询去数据库的 User 表里查。从数据库设计层面User 表不是业务表不需要搞太复杂字段就是user_id,username,password三个。密码字段的存储讲究一点的话可以存 MD5 或 SHA-256 的哈希值但要注意 Java 里算出来的哈希要转成十六进制字符串再存进数据库直接存字节数组会出现字符集问题。对于课设和内部工具明文密码虽然不推荐但也不至于罪大恶极只是你一定要给后来接手的人留一句注释提醒这是一笔技术债。实际的登录校验代码长这样核心就是PreparedStatement的参数绑定禁止用字符串拼接public User login(String username, String password) { String sql SELECT user_id, username, password FROM [User] WHERE username ? AND password ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, password); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { User u new User(); u.setUserId(rs.getInt(user_id)); u.setUsername(rs.getString(username)); u.setPassword(rs.getString(password)); return u; } } } catch (SQLException e) { e.printStackTrace(); } return null; }注意 SQL 里[User]带了方括号。因为USER是 SQL Server 的系统保留字不加方括号这条 SQL 直接报语法错误这是 SQL Server 和其他数据库不太一样的地方。PreparedStatement的参数用?占位ps.setString(1, ...)从 1 开始计数和 JDBC 的惯例一致不要想当然从 0 开始。登录界面拿到null就弹窗提示“用户名或密码错误”拿到 User 对象就dispose()当前窗口并打开主窗体。密码错误时最好不要区分“用户不存在”和“密码错误”直接给同一个提示免得被人枚举出哪些账号存在。4.2 学生信息列表JTable 绑定 ResultSet 的最小实现列表展示在学籍管理系统里是大头。JTable 的数据模型是TableModel最简单的是把数据库查出来的 List 转成二维数组再塞给DefaultTableModel。这个方式数据量小的时候完全够用。具体做法是先查 Student 表并关联 Class 表拿到班级名称然后把每行数据的字段抽出来放进Object[]。这里有个小设计表格里展示班级名称让用户看得懂但修改时提交的是class_id这样就避免了用户看到一串数字不知所云的问题。以下是 DAO 层查询所用 SQL注意LEFT JOIN而不是INNER JOIN。为什么因为有的学生可能还没分班class_id 是 NULLINNER JOIN会把这类学生丢掉界面上就看少人了而LEFT JOIN会保留学生记录班级名显示 NULL。SELECT s.student_id, s.student_name, s.gender, s.birth_date, c.class_name, s.phone FROM Student s LEFT JOIN Class c ON s.class_id c.class_id ORDER BY s.student_id;ORDER BY s.student_id在这里很重要。如果不排序SQL Server 返回行的顺序是不保证的这次运行按学号排下次可能按物理存储顺序排。用户会看到表格里的行顺序抖来抖去第一反应是“程序出 bug 了”。这其实是数据层的玄学但加个 ORDER BY 就能治。4.3 新增与编辑表单校验是写在 GUI 层还是 DAO 层新增和编辑弹窗可以共用一个表单。我的习惯是做一个StudentDialog构造时传入一个 Student 对象传了就是编辑模式没传就是新增模式。这样能省掉一半重复代码也不容易出现两套表单字段不一致的问题。表单校验我分两层写。GUI 层做必填项和非空校验比如学号、姓名不能为空性别必须在下拉框选一个DAO 层做业务校验比如学号是否重复。这两层的职责不要搞混GUI 层的校验目的是提升交互体验DAO 层的校验目的是保证数据完整性。如果只在 GUI 层校验那绕过界面直连数据库的调用就把脏数据写进去了如果只在 DAO 层校验用户的错误输入会变成“操作失败请重试”这种莫名其妙的提示。新增学生时学号重复的处理是重点。下面这段代码通过SELECT COUNT(*)来预检查虽然存在并发间隙但在桌面单机场景下完全够用public boolean insertStudent(Student s) { String checkSql SELECT COUNT(*) FROM Student WHERE student_id ?; String insertSql INSERT INTO Student (student_id, student_name, gender, birth_date, class_id, phone) VALUES (?, ?, ?, ?, ?, ?); try (Connection conn DBUtil.getConnection(); PreparedStatement checkPs conn.prepareStatement(checkSql)) { checkPs.setString(1, s.getStudentId()); try (ResultSet rs checkPs.executeQuery()) { rs.next(); if (rs.getInt(1) 0) { return false; // 学号已存在返回 false 由界面层提示 } } try (PreparedStatement insertPs conn.prepareStatement(insertSql)) { insertPs.setString(1, s.getStudentId()); insertPs.setString(2, s.getStudentName()); insertPs.setString(3, s.getGender()); insertPs.setDate(4, s.getBirthDate() null ? null : new java.sql.Date(s.getBirthDate().getTime())); insertPs.setInt(5, s.getClassId()); insertPs.setString(6, s.getPhone()); return insertPs.executeUpdate() 1; } } catch (SQLException e) { e.printStackTrace(); return false; } }这里有几个容易翻车的细节。java.sql.Date是java.util.Date的子类但两者在 JDBC 中不能直接混用ps.setDate接受的是java.sql.Date。如果你从日期选择器拿到的是java.util.Date要手动转一下。birth_date为 NULL 时setDate(4, null)是安全的不必额外处理。class_id如果用户没选班级表单传 0 还是 -1 都行但一定不要传默认的 0 进数据库因为 Class 表里大概率没有 id0 的记录外键约束直接拒绝这条插入。4.4 成绩录入与级联删除事务和约束的边界成绩表的录入相对简单一条 INSERT 搞定。但有一个点值得认真讨论删除学生时要不要连他的成绩一起删除。如果学生退学了他的档案和成绩留在库里会导致统计出错如果直接硬删 Student 记录Score 表的外键约束会报错删除失败。我的选择是在主界面上提供“删除学生”按钮弹出确认框提示“将同时删除该生所有成绩记录”然后用一个事务把两个操作包起来。事务的意义在于如果删除成绩成功但删除学生失败数据库不会停留在“成绩没了但学生还在”的中间状态。public boolean deleteStudent(String studentId) { String deleteScoreSql DELETE FROM Score WHERE student_id ?; String deleteStudentSql DELETE FROM Student WHERE student_id ?; try (Connection conn DBUtil.getConnection()) { conn.setAutoCommit(false); try (PreparedStatement ps1 conn.prepareStatement(deleteScoreSql); PreparedStatement ps2 conn.prepareStatement(deleteStudentSql)) { ps1.setString(1, studentId); ps1.executeUpdate(); ps2.setString(1, studentId); int rows ps2.executeUpdate(); conn.commit(); return rows 1; } catch (SQLException e) { conn.rollback(); throw e; } } catch (SQLException e) { e.printStackTrace(); return false; } }事务开启的关键是conn.setAutoCommit(false)。不关掉自动提交的话第一条 DELETE 执行完就立刻提交了后续操作失败也悔之晚矣。rollback()是后悔药但前提是你在异常分支里调了它并且连接没有被提前关闭。这个代码里 try-with-resources 的嵌套结构保证了连接复用和异常回滚路径都正确。另外一个很多人忽略的细节conn.rollback()之后没有重新setAutoCommit(true)。虽然马上连接会关闭但在连接池场景下连接状态会被污染。这里直连不用连接池影响不大但如果你以后把这段代码搬到 Web 项目里记得在 finally 里恢复自动提交。5. 避坑指南从百度和搜索引擎里真心搜不到的问题记录5.1 连接 SQL Server 报错TCP 连接被强行终止现象Java 程序启动时连接数据库控制台抛The TCP/IP connection to the host localhost, port 1433 has failed而本机 SSMS 却连得好好的一点问题没有。原因这条报错九成是 SQL Server 的 TCP/IP 协议没启用SSMS 走的是共享内存或命名管道所以不受影响。剩下一成才是防火墙拦截了 1433 端口。解决打开 SQL Server 配置管理器 - SQL Server 网络配置 - 实例名的协议右键 TCP/IP 选择启用然后重启 SQL Server 服务。如果确定协议已启用再去 Windows 防火墙入站规则里放行 1433 端口。重启服务这个动作千万不能省只改配置不重启配置不会生效这是很多人忽略的“改了没用”的原因。5.2 连接串没加 encryptfalse驱动直接要求 SSL现象SQL Server 2019 以后Java 程序连接时报The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption程序完全起不来。原因新版微软 JDBC 驱动9.x 以上默认encrypttrue而 SQL Server 默认没有安装证书两者碰一起就强制握手失败。这属于新驱动与旧库的兼容性问题。解决在 JDBC URL 末尾加上;encryptfalse。如果你的 SQL Server 版本较旧不加可能也能跑但加了不会有什么坏事所以我建议不管怎样都加上。如果公司安全策略不允许明文传输那就不能简单关了事你得去 SQL Server 里配置证书后把encrypttrue保留并加上trustServerCertificatetrue绕过客户端对证书链的校验。5.3 中文乱码的根源在 NVARCHAR 而不是 Java 编码现象界面表格里中文显示正常但数据库里看到的是乱码或者反过来数据库里正常界面上是问号。原因SQL Server 的排序规则Collation默认可能是Chinese_PRC_CI_AS配合VARCHAR存储中文时走的是数据库代码页JDBC 读写时编码转换不对就会出乱码。绝大多数情况下乱码不是 Java 文件编码的问题而是建表时用了VARCHAR而不是NVARCHAR。解决把所有可能存中文的字段统一改成NVARCHAR。这是一个从建表层面就一劳永逸的解法。如果表已经建好了用ALTER TABLE Student ALTER COLUMN student_name NVARCHAR(50);把列类型改掉。就算你 Java 代码里文件编码完全正确也要先确认数据库这侧的类型是NVARCHAR才谈得上排查后续。5.4 界面卡死是 GUI 线程里跑 SQL 的必然结果现象点击“查询”按钮后如果数据量一大整个窗口就变成“白板”拖动窗口也没反应过好几秒才恢复。原因Swing 是单线程模型所有界面渲染和事件处理都在 EDTEvent Dispatch Thread上执行。你在按钮的 ActionListener 里直接跑 JDBC 查询数据库响应慢一点EDT 就被阻塞了界面整个冻结。这不是死锁是线程模型决定的“卡死”假象。解决把数据库操作丢到后台线程去执行。最简做法是new Thread(() - { ... }).start()或者用SwingWorkerT, V。查询完成后通过SwingUtilities.invokeLater()回到 EDT 更新界面。这个改动对所有查询、删除、导入功能都适用它不会让程序跑得更快但会让界面看起来“活”着用户体验是完全不同的。SwingWorkerVoid, Object worker new SwingWorkerVoid, Object() { Override protected Void doInBackground() throws Exception { ListStudent list studentDao.searchStudents(keyword); SwingUtilities.invokeLater(() - { DefaultTableModel model (DefaultTableModel) table.getModel(); model.setRowCount(0); for (Student s : list) { model.addRow(new Object[]{s.getStudentId(), s.getStudentName(), s.getGender(), s.getClassId()}); } }); return null; } }; worker.execute();5.5 SQL Server 写入性能异常别忽视 WRITELOG 等待现象批量导入几百条学生记录时SQL Server 偶尔出现写入极慢的窗口期看起来像程序卡死。原因SQL Server 的日志写入是串行化的如果有一个大事务一直没提交后续的小事务在等待写日志时会出现WRITELOG类型的等待。说直白点就是“日志写盘排队了”。这在桌面系统里少见但批量导入、一次性删大量数据时容易触发。解决批量操作时不要在一个事务里塞几千条记录。SQL Server 的日志写入模型决定了长事务对并发性能非常不友好。把批量新增拆成每 100 条提交一次能看到立竿见影的效果。另外确认数据库文件的autogrowth设置不是按“百分比”增长而是按固定 MB 增长避免文件扩容时的等待。6. 更进一步让学籍系统从“能跑”变成“好用”到这一步系统的增删改查已经完整了但距离“能交付给别人用”还差几件事。第一件是操作日志。学籍数据属于敏感数据谁在什么时间改了哪个学生的信息如果完全没有记录出了问题只能干瞪眼。加一张OperationLog表字段是log_id,user_id,action,target,log_time在 DAO 层每个修改操作后面补一条 INSERT 即可。工作量不大但对系统的可信度提升是质的飞跃。第二件是数据校验再往前一步。现在只在录入时做了基础校验但成绩表的场景里同一个人同一门课的成绩应该只允许录入一次这一点我在数据库设计时用联合主键已经挡了一刀。更细的校验是转班操作时要校验目标班级是否存在这个用前端下拉列表已经解决了大半。第三件是导出功能。JTable 的数据可以一键导出 CSV用FileWriter写文本文件就行不需要引入 POI 那套重型依赖。最后一件事也是最容易踩的坑数据库备份。你做了半天的数据没有备份等于随时归零。用 SQL Server 的BACKUP DATABASE StudentMS TO DISK D:\backup\StudentMS.bak;定期做一次完整备份比任何代码优化都有价值。我自己就经历过一次硬盘坏道导致数据库文件损坏的事故那种绝望不希望你也体验一次。从那以后我的习惯是每次交付前除了导出一份数据库脚本留底再导出一份 bak 备份文件。这是最简单的后悔药。学籍管理系统的核心价值不在功能有多花哨而在于数据经手环节的每一步都可靠可追溯。把上述四点逐项做完这个项目从“课设”到“能拿去给教务科试运行”的差距就只剩时间了。希望我的这些血泪经验帮你在做系统时少走几段弯路早点把时间花在真正有增量的功能上。本文还有配套的精品资源点击获取