简介：面向数据库系统课程设计与Java Web开发的综合实战资源，以高校图书馆管理为业务场景，提供完整Java源码与SQL数据库脚本，适合计算机相关专业学生完成课程设计、毕业设计，也适合初学者演练前后端分离项目。资源共277个文件，压缩包30.91MB，主要包括49个Java源文件、86个XML配置、32个JS脚本、31个Vue页面，以及4个SQL建库脚本与CSS样式、PNG图标等辅助文件，后端逻辑与前端界面均有覆盖。已有1488人学习下载。通过这份资源可快速搭建一套可运行的图书馆管理系统，理解借阅管理、图书检索、读者管理等核心模块的程序实现，并借助SQL脚本掌握数据表设计与初始化流程，梳理从页面交互到持久化存储的完整链路，为数据库课程设计或毕业设计提供可直接参考与二次开发的完整方案。
1. 数据库课程设计选图书馆管理系统：为什么这个题目最稳、也最容易被做烂
每年的数据库系统课程设计选题，十个组里有六七个都在做图书馆管理系统，java 方向尤其多。问过不少答辩现场翻车的同学，问题几乎出在同一处：系统能跑，但数据库设计撑不住答辩老师的追问——为什么这张表要冗余这个字段？为什么借阅记录没有保留历史？为什么并发借同一本书会超借？这个标题给的“Java 图书馆管理系统源码 + 数据库”，本质上是一个完整的交付包，源码负责演示功能，数据库脚本负责支撑逻辑。它的价值在于让你在最短时间内理清“业务→表结构→代码→演示”这条链路，而不是重新发明轮子。适合三类人：正在做课程设计需要快速落地的学生，想搞懂 Java + JDBC + MySQL 怎么串成完整项目的人，以及打算在简历上写“独立完成图书馆管理系统”的求职者。但拿到源码包只是起点，能把这套系统的表设计和事务逻辑讲明白，才算真正把它变成自己的东西。
2. 先把数据模型立住：图书馆管理系统的表设计、关系与范式落地
2.1 从借书场景倒推实体：图书、读者、管理员、借阅记录缺一不可
做课程设计最容易犯的错是先把界面画出来再想表结构，正确顺序恰好相反。我一般会拿一张纸，把借书的完整流程写一遍：读者登录、检索图书、确认借阅、管理员登记、设定应还日期、归还时检查是否逾期。每一步涉及谁、产生了什么数据，实体就出来了。
最少需要四张表：图书表存书目信息，读者表存借阅人，管理员表存系统操作者，借阅记录表存每一次借还行为。不要只建三张表然后让借阅记录挂在图书表里，那样一旦同一本书被借两次，历史记录就全乱了。借阅记录是典型的事实表，它记录的是“某时某刻谁借了哪本书”这个事件，必须独立存在。
再做一层细化：图书表里应该有 ISBN、书名、作者、出版社、分类、库存总量、当前可借数量。读者表里有读者编号、姓名、联系方式、办证日期、状态。借阅记录表里有借阅 ID、读者编号、图书编号、借出时间、应还时间、实际归还时间、状态。管理员表最简单，账号密码加姓名。
2.2 关系模式与主外键：为什么借阅表要冗余 book_name 和 reader_name
四张表的关系模式看起来直接：借阅记录通过 reader_id 关联读者表，通过 book_id 关联图书表，这是标准的两个外键。但实际做课程设计时，我建议在借阅记录表里额外冗余两个字段：book_name 和 reader_name。
这不符合第三范式，但符合课程设计的实际需要。想想看，借阅记录列表页要显示书名和读者名，如果不冗余，每次查询都要 JOIN 两张表。更关键的是，图书和读者的信息可能后续被修改或删除，如果借阅历史里只存了 ID，改名之后历史记录显示的名字就变了。冗余两个名称字段，相当于给借阅历史拍了张快照，这在真实的图书管理业务里也是常见的做法。
答辩时老师大概率会问“为什么冗余”，标准回答是：借阅记录是历史事实，业务上要求保留借出时刻的书名和读者名，所以这里做反范式设计。这个回答比“为了查询快”更有说服力。
2.3 建表 SQL 完整脚本：范式与反范式的取舍
以下是我整理过的最小可用建表脚本，数据库用 MySQL 5.7 以上版本，字符集和排序规则这两行建议照用，能省掉后面很多乱码问题。
-- 创建数据库，指定字符集，避免中文乱码 CREATE DATABASE IF NOT EXISTS library_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE library_db; -- 管理员表 CREATE TABLE admin ( admin_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, real_name VARCHAR(50) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 图书表 CREATE TABLE book ( book_id INT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL, book_name VARCHAR(100) NOT NULL, author VARCHAR(50), publisher VARCHAR(100), category VARCHAR(30), total_stock INT DEFAULT 1, avail_stock INT DEFAULT 1, INDEX idx_book_name (book_name), INDEX idx_category (category) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 读者表 CREATE TABLE reader ( reader_id INT PRIMARY KEY AUTO_INCREMENT, reader_no VARCHAR(20) NOT NULL UNIQUE, reader_name VARCHAR(50) NOT NULL, phone VARCHAR(20), reg_date DATE, status TINYINT DEFAULT 1 -- 1正常 0冻结 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 借阅记录表，冗余存名称字段，保留历史快照 CREATE TABLE borrow_record ( borrow_id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, book_name VARCHAR(100) NOT NULL, reader_id INT NOT NULL, reader_name VARCHAR(50) NOT NULL, borrow_date DATE NOT NULL, due_date DATE NOT NULL, return_date DATE, status TINYINT DEFAULT 0, -- 0借出 1已还 2逾期未还 FOREIGN KEY (book_id) REFERENCES book(book_id), FOREIGN KEY (reader_id) REFERENCES reader(reader_id), INDEX idx_status (status), INDEX idx_reader (reader_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这段脚本的逻辑核心有四点。第一，所有表都用 InnoDB，因为后续借书归还操作涉及事务回滚，MyISAM 不支持事务，这条别忽略。第二，book_name 和 reader_name 在借阅记录里冗余存储，是刻意为之的反范式设计，用来保证历史记录的可读性和稳定性。第三，借阅记录表对 status 和 reader_id 建了索引，因为最频繁的查询就是“某个读者当前借了哪些书”和“哪些书逾期未还”，没有索引数据量一上去就慢。第四，avail_stock 和 total_stock 拆成两个字段，为的是借书时只减 avail_stock，还书时再加回来，不需要动 total_stock。
2.4 初始数据与演示账号：让交付包打开就能跑
建完表要顺手写初始数据脚本，否则答辩现场从空表开始演示，查询结果空荡荡的，效果很差。演示数据我一般分三类准备：第一类是管理员账号，一个 root 账号密码建议用明文，方便答辩时现场登录；第二类是图书数据，至少放 15 到 20 本，覆盖文学、计算机、历史三个分类，数量多但别乱，每本都填全 ISBN、作者、出版社；第三类是读者数据，5 个左右即可，其中有 1 个读者故意让他有一条逾期未还的记录，演示罚款和催还功能时直接有素材。
插入数据时必须注意外键顺序——先插图书和读者，再插借阅记录，否则外键约束会直接报错。这也是最常见的初始化失败原因。主键自增列不要手工指定值，让数据库自己分配，否则后面对不上。
-- 初始化管理员 INSERT INTO admin (username, password, real_name) VALUES ('admin', '123456', '系统管理员'); -- 初始化图书 INSERT INTO book (isbn, book_name, author, publisher, category, total_stock, avail_stock) VALUES ('978-7-111-12345-6', 'Java编程思想', '某作者', '某工业出版社', '计算机', 5, 5), ('978-7-302-23456-7', '数据库系统概论', '某作者', '某大学出版社', '计算机', 3, 3); -- 初始化读者 INSERT INTO reader (reader_no, reader_name, phone, reg_date, status) VALUES ('R001', 'A同学', '13800000001', '2024-09-01', 1), ('R002', 'B同学', '13800000002', '2024-09-02', 1); -- 初始化一条已借出记录，演示时直接有素材 INSERT INTO borrow_record (book_id, book_name, reader_id, reader_name, borrow_date, due_date, status) VALUES (1, 'Java编程思想', 1, 'A同学', '2025-03-01', '2025-03-15', 0);3. Java 技术选型与工程结构：Swing 还是 Web？JDBC 怎么封装才不答辩翻车
3.1 技术栈选择的现实约束：课程设计要的是“看得见、讲得清”
Java 图书馆管理系统的界面层有两种主流做法：Swing 桌面端和 JSP/Servlet Web 端。选题时先想清楚一个问题——答辩现场的环境靠不靠谱。Web 端要跑 Tomcat，要配上下文路径，还要保证浏览器兼容，现场翻车概率高；Swing 打包成 jar 双击就能跑，依赖只有 JDK 和 MySQL，演示链路短得多。
我建议课程设计优先选 Swing。不是说 Web 端不好，而是课程设计的核心评价点是数据库设计和代码逻辑，不是框架先进性。Swing 能把所有注意力集中在“表设计是否合理、事务是否完整、SQL 是否规范”这几件真正重要的事上。而且 Swing 的 UI 代码写起来直观，每个按钮对应一个事件监听器，逻辑链路清楚，答辩讲解时不容易卡壳。
另一个约束是 JDK 环境。Swing 项目用 JDK 8 最稳妥，JDK 9 以上模块化之后有些 Swing 相关的 API 使用方式有变化，没必要在这个环节给自己加风险。工程结构上，参考最常见的 Java 分层写法，不引入 Spring，纯 JDBC 操作数据库，理由是全链路都是自己写的，每一个类都能解释清楚，不会有“这行代码是框架自动完成的”这种回答不上来的局面。
3.2 工程目录与类的职责划分：entity / dao / service / ui 四层
一个能让答辩老师满意的 Swing 工程，目录结构建议分成四层，这是 Java 项目最常见的分包方式，也最容易讲清楚。
src/ ├── com/libmanage/entity/ -- 实体类，对应四张表 │ Admin.java │ Book.java │ Reader.java │ BorrowRecord.java ├── com/libmanage/dao/ -- 数据访问层，只写 SQL │ AdminDao.java │ BookDao.java │ ReaderDao.java │ BorrowRecordDao.java ├── com/libmanage/service/ -- 业务逻辑层，事务在这里控制 │ BorrowService.java │ ReturnService.java │ StatService.java ├── com/libmanage/db/ -- 数据库连接工具 │ DBUtil.java └── com/libmanage/ui/ -- Swing 界面 LoginFrame.java MainFrame.java BookManagePanel.java这个分层的逻辑一句话就能说清：entity 是数据的载体，dao 负责跟数据库对话，service 处理业务规则，ui 只管展示和收集用户输入。答辩时如果被问到“为什么这么分”，回答“为了让 SQL 只出现在 dao 层，业务规则只出现在 service 层，界面层不碰 SQL”——这句话本身就是加分项。
3.3 JDBC 工具类 DBUtil 与连接参数：驱动、URL、时区这三个坑
DBUtil 是整个项目的地基，它的职责只有两个：加载驱动、提供连接。下面是经过多次课程设计和实际项目验证过的写法，注意注释里标出来的三个坑。
package com.libmanage.db; import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class DBUtil { // 驱动的类名，MySQL 5.7 对应 com.mysql.jdbc.Driver // MySQL 8.x 对应 com.mysql.cj.jdbc.Driver，注意包名多了 cj private static final String DRIVER = "com.mysql.cj.jdbc.Driver"; // useSSL=false 避免连接时 SSL 握手警告 // serverTimezone=Asia/Shanghai 解决时区导致的时间差 8 小时问题 // characterEncoding=utf8 保证中文字符正确传输 private static final String URL = "jdbc:mysql://localhost:3306/library_db?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8"; private static final String USER = "root"; private static final String PWD = "123456"; static { try { // 1. 注册驱动，MySQL 8.x 必须用 com.mysql.cj.jdbc.Driver Class.forName(DRIVER); } catch (ClassNotFoundException e) { e.printStackTrace(); } } // 2. 每次调用都新建连接，课程设计级别够用 public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PWD); } // 3. 关闭连接的统一入口，防止漏关 public static void close(AutoCloseable... resources) { for (AutoCloseable r : resources) { if (r != null) { try { r.close(); } catch (Exception e) { e.printStackTrace(); } } } } }这段代码的三个参数值得展开说。第一个是驱动类名，MySQL 5.7 和 8.x 的驱动类名不一样，5.7 是 com.mysql.jdbc.Driver，8.x 是 com.mysql.cj.jdbc.Driver，用错了直接 ClassNotFoundException，而且这个报错信息很容易让人误以为是缺 jar 包。第二个是 serverTimezone，不加这个参数，MySQL 8.x 连接时会报时区错误，即使连接成功，日期字段也可能差 8 个小时。第三个是 characterEncoding=utf8，这里的 utf8 要和数据库建库时的 utf8mb4 对应，否则中文在传输过程中可能变成问号。
连接池在这个项目里不需要引入。课程设计的数据量撑不起连接池的收益，反而会引入额外依赖，答辩时还要解释为什么用连接池——没必要。每次操作新建连接、用完关闭，简单直接。
3.4 DAO 层实现借阅与归还：事务是课程设计最容易忽略的细节
借书这个操作在 DAO 层看起来是两条 SQL：一条往 borrow_record 插入记录，一条把 book 表的 avail_stock 减一。但这两步必须放在同一个事务里，否则就会出现“插入了借阅记录但库存没减”或者反过来“库存减了但没记录”的数据不一致。
// 借书事务：插入借阅记录 + 扣减库存，要么都成功，要么都回滚 public boolean borrowBook(int bookId, int readerId) { Connection conn = null; PreparedStatement ps1 = null; PreparedStatement ps2 = null; try { conn = DBUtil.getConnection(); // 关闭自动提交，开启事务 conn.setAutoCommit(false); // 1. 插入借阅记录，书名和读者名从关联表查出来冗余存储 String sqlInsert = "INSERT INTO borrow_record " + "(book_id, book_name, reader_id, reader_name, borrow_date, due_date, status) " + "SELECT ?, book_name, ?, reader_name, CURDATE(), DATE_ADD(CURDATE(), INTERVAL 30 DAY), 0 " + "FROM book, reader WHERE book.book_id = ? AND reader.reader_id = ?"; ps1 = conn.prepareStatement(sqlInsert); ps1.setInt(1, bookId); ps1.setInt(2, readerId); ps1.setInt(3, bookId); ps1.setInt(4, readerId); int insertCount = ps1.executeUpdate(); // 2. 扣减可借库存，加条件 avail_stock > 0 防止超借 String sqlUpdate = "UPDATE book SET avail_stock = avail_stock - 1 " + "WHERE book_id = ? AND avail_stock > 0"; ps2 = conn.prepareStatement(sqlUpdate); ps2.setInt(1, bookId); int updateCount = ps2.executeUpdate(); // 两步都影响 1 行才提交，否则回滚 if (insertCount == 1 && updateCount == 1) { conn.commit(); return true; } else { conn.rollback(); return false; } } catch (SQLException e) { try { if (conn != null) conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } e.printStackTrace(); return false; } finally { DBUtil.close(ps1, ps2, conn); } }这里有两个细节是答辩常问的。第一个是 conn.setAutoCommit(false) 之后的 conn.commit() 和 conn.rollback()，这是事务的标准写法，注意 catch 块里回滚时也要包一层 try-catch，因为回滚本身也可能抛异常。第二个是 UPDATE 语句加了 avail_stock > 0 这个条件，这是防超借的关键——如果两个人同时借同一本只剩一本的书，两条 UPDATE 同时执行，只会有一条影响行数为 1，另一条为 0，后者的 where 条件已经不满足了，自然就回滚了。
4. 核心功能实现：图书借阅、归还、逾期计算与排行榜的完整代码路径
4.1 登录与权限控制：三个角色怎么在 UI 层做路由
图书馆管理系统的最小角色集是两个：管理员和读者。管理员可以操作图书维护、读者管理、借还书，读者只能查书和看自己的借阅记录。在做 Swing 界面时，角色路由的常见做法不是搞权限框架，而是在登录成功之后，根据角色决定打开哪个主界面。
登录的 SQL 查询要注意一个细节：管理员表和读者表是分开的，登录时要先区分用户类型。一般设计上，登录界面放一个下拉框选择“管理员 / 读者”，或者用两个不同的登录入口。
// 登录验证：分别查管理员表和读者表 public Object login(String username, String password, String role) { if ("admin".equals(role)) { // 查 admin 表 String sql = "SELECT * FROM admin WHERE username = ? AND password = ?"; // 查到了就返回 Admin 对象，否则返回 null } else { // 查 reader 表，reader_no 作为登录账号 String sql = "SELECT * FROM reader WHERE reader_no = ? AND status = 1 AND phone = ?"; // 返回 Reader 对象 } }读者表登录用 phone 当密码不是一个好设计，但课程设计里为了演示方便，我见过不少人直接这么干。更好的做法是在读者表加一个单独的 password 字段，跟 admin 表保持一致。如果你要做得更规范，就在读者表加 login_pwd 列，别再拿 phone 凑数。登录成功后在 MainFrame 里根据角色设置菜单可见性——管理员能看到“图书管理”和“读者管理”菜单，读者只能看到“图书检索”和“我的借阅”。这个在 Swing 里就是 setVisible 的控制，逻辑简单但演示效果很好。
4.2 图书查询与分页：PreparedStatement 防注入的示范点
图书查询是课程设计里躲不开的功能点，也是展示 SQL 功底的窗口。用关键字模糊匹配书名和作者，这是最常见的需求。这里必须用 PreparedStatement，不能用字符串拼接，后者既有注入风险，又容易在中文参数下出乱码。
// 按关键字分页查询图书 public List<Book> searchBooks(String keyword, int page, int pageSize) { List<Book> books = new ArrayList<>(); // 计算偏移量，page 从 1 开始 int offset = (page - 1) * pageSize; String sql = "SELECT * FROM book WHERE book_name LIKE ? OR author LIKE ? " + "ORDER BY book_id LIMIT ? OFFSET ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { // 通配符拼接在参数里，而不是拼在 SQL 字符串里 ps.setString(1, "%" + keyword + "%"); ps.setString(2, "%" + keyword + "%"); ps.setInt(3, pageSize); ps.setInt(4, offset); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { Book book = new Book(); book.setBookId(rs.getInt("book_id")); book.setBookName(rs.getString("book_name")); book.setAuthor(rs.getString("author")); book.setPublisher(rs.getString("publisher")); book.setAvailStock(rs.getInt("avail_stock")); books.add(book); } } } catch (SQLException e) { e.printStackTrace(); } return books; }这段代码有两点值得在答辩时主动讲。第一，LIMIT ? OFFSET ? 是 MySQL 的分页写法，问号占位符让 PreparedStatement 来处理参数，避免注入。第二，LIKE 的通配符 % 要拼在 setString 的参数值上，不能拼在 SQL 模板字符串里。如果写成 WHERE book_name LIKE '%?%'，PreparedStatement 会把问号当字面量处理，查出来永远是空。这个错误我见过不少同学踩过，答辩现场改不出来直接冷场。
分页还需要一个配套的统计总数方法，SELECT COUNT(*) FROM book WHERE book_name LIKE ? OR author LIKE ?，把总数除以 pageSize 得到总页数。这两段代码一般是成对出现的，建议写到同一个 DAO 类里。
4.3 借书与还书的事务逻辑：状态字段 + 流水表双写
上一章已经给了借书的事务代码，这里重点说还书。还书比借书多一个判断：是否逾期。还书时的核心操作有两步：更新 borrow_record 的状态和归还日期，把 book 表的 avail_stock 加一。同样需要事务。
// 还书事务：更新借阅记录 + 回补库存 public boolean returnBook(int borrowId, int bookId) { Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 1. 更新借阅记录：设置实际归还日期、状态改为已还 String sqlUpdateRecord = "UPDATE borrow_record SET return_date = CURDATE(), " + "status = CASE WHEN return_date IS NULL AND CURDATE() > due_date THEN 2 " + "ELSE 1 END WHERE borrow_id = ? AND status = 0"; PreparedStatement ps1 = conn.prepareStatement(sqlUpdateRecord); ps1.setInt(1, borrowId); int updateCount = ps1.executeUpdate(); // 2. 回补库存 String sqlUpdateStock = "UPDATE book SET avail_stock = avail_stock + 1 WHERE book_id = ?"; PreparedStatement ps2 = conn.prepareStatement(sqlUpdateStock); ps2.setInt(1, bookId); ps2.executeUpdate(); if (updateCount == 1) { conn.commit(); return true; } else { conn.rollback(); return false; } } catch (SQLException e) { e.printStackTrace(); try { if (conn != null) conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } return false; } }还书时用了一个比较巧的 SQL 写法：CASE WHEN 结合 CURDATE() 判断是否逾期，如果当前日期大于应还日期，status 直接置为 2，否则置为 1。这样一步就能区分“按时还”和“逾期还”，不需要在 Java 代码里做日期比较。注意 UPDATE 的 WHERE 条件里有 status = 0，这是为了防止同一笔借阅记录被重复还两次——第二次执行时 status 已经是 1 了，影响行数为 0，事务回滚。
4.4 逾期罚款计算：用 SQL 算还是用 Java 算
逾期罚款是图书馆管理系统里最能体现业务逻辑的功能点。我见过两种做法：一种是在 Java 代码里用 LocalDate 计算天数再乘以单价，一种是在 SQL 里用 DATEDIFF 直接算出来。两种都对，但课程设计建议用 SQL 算，原因很实际：罚款金额最终要展示在表格里，用 SQL 算出来的字段直接填充到 ResultSet 里，代码更少，也不容易出日期格式转换的 bug。
-- 查询所有逾期未还的记录，并计算罚款金额 SELECT br.borrow_id, br.book_name, br.reader_name, br.borrow_date, br.due_date, DATEDIFF(CURDATE(), br.due_date) AS overdue_days, DATEDIFF(CURDATE(), br.due_date) * 0.5 AS fine_amount FROM borrow_record br WHERE br.status = 0 AND br.due_date < CURDATE() ORDER BY br.due_date ASC;这条 SQL 的查询条件有两层：status = 0 表示借出未还，due_date < CURDATE() 表示已经过了应还日期还没还。罚款金额按每天 0.5 元计算，DATEDIFF 返回的是两个日期之间相差的天数。实际执行时注意一个边界：当天借当天还 DATEDIFF 是 0，不罚；还书日期比应还日期晚一天，DATEDIFF 是 1，罚 0.5 元。
用 SQL 算罚款的好处是，数据直接渲染到 JTable 里，不用在 Java 层再写一坨循环和判断。如果你想把罚款弄得再像样一点，可以加一个规则：超过 30 天未还，按每天 1 元计算。这个用 CASE WHEN 写在 SQL 里同样能实现，而且演示效果很好——老师一看就知道你考虑了阶梯计费。
4.5 数据统计与报表：排行榜、分类占比的最小实现
课程设计的功能清单里如果只写“增删改查”，答辩会觉得单薄。加一个数据统计模块，成本低、效果明显，而且能展示 SQL 的聚合函数能力。我一般加两个统计：借阅排行榜和图书分类占比。
-- 借阅排行榜：统计每本书被借了多少次 SELECT book_name, COUNT(*) AS borrow_count FROM borrow_record GROUP BY book_name ORDER BY borrow_count DESC LIMIT 10; -- 分类占比：统计每个分类的图书数量 SELECT category, COUNT(*) AS book_count, ROUND(COUNT(*) * 100.0 / (SELECT COUNT(*) FROM book), 2) AS percent FROM book GROUP BY category;排行榜这条 SQL 用了 GROUP BY 加 COUNT，按借阅次数降序取前十。分类占比那条用了一个子查询算总数，ROUND 保留两位小数得到百分比。这两条 SQL 在 Swing 里用一个 JTable 展示，数据源就是 ResultSet。统计模块的实现代码非常简单，但答辩时能引出不少话题：为什么用 GROUP BY、为什么用子查询、百分比怎么算的——这些都是数据库课程的重点内容，提前准备好回答就是送分题。
5. 打包交付避坑：从源码 zip 到可跑的课程设计，这 5 个坑最常翻车
5.1 数据库脚本在新机器上执行报错：字符集与版本差异
现象：把源码和 SQL 脚本发给同学，他在自己电脑上执行建表脚本，一插入中文就报错，或者表建成功了但查询出来全是问号。
原因：MySQL 客户端默认字符集跟脚本里的 utf8mb4 不一致。最常见的是 MySQL 服务端 character_set_server 还是 latin1，或者客户端连接时没指定字符集。另一个版本差异是，老版本 MySQL 5.5 不支持 utf8mb4，执行建表语句直接报错。
解决：第一，在 SQL 脚本开头写 SET NAMES utf8mb4;，让客户端、连接、结果集三处都切到 utf8mb4。第二，建库语句明确写 DEFAULT CHARACTER SET utf8mb4，不要依赖服务端默认值。第三，如果目标机器是 MySQL 8.x，建的库默认就是 utf8mb4，脚本反而没问题；如果是 5.7 就要注意数据库实例的配置文件里 character_set_server 的值。
5.2 JDBC 驱动没打包进 lib，换电脑就 ClassNotFoundException
现象：在自己电脑上运行一切正常，把项目导出成 jar 包发给别人，双击运行直接报 ClassNotFoundException，错误信息里写着 com.mysql.cj.jdbc.Driver。
原因：Eclipse 或 IDEA 里运行项目时，依赖的 jar 包由 IDE 自动加到 classpath；但导出 jar 包时，如果没把 mysql-connector-java 这个驱动包放到 jar 包的 lib 目录下，换一台没有配过 classpath 的机器，驱动类就找不到。
解决：打包时用“导出可运行 jar 包”的方式，把依赖的库复制到 jar 包旁边，或者在 manifest 文件里指定 Class-Path。常见做法是建一个 lib 目录把 mysql-connector-java-x.x.x.jar 放进去，然后用 Eclipse 的 Export → Runnable JAR File → “Copy required libraries into a sub-folder next to the JAR”。这样 jar 包和 lib 目录一起拷走，驱动就不丢。自己在打包之后先删掉本地的驱动 jar，再从 lib 目录跑一次 java -jar，验证能不能起来。
5.3 时区问题导致连接报错：serverTimezone 的两种写法
现象：代码在自己机器上正常，换一台电脑连接 MySQL 8.x 时，控制台报错：The server time zone value '???ú±ê׼ʱ¼ä' is unrecognized。
原因：MySQL 8.x 的驱动对时区要求严格，数据库服务端的时区没设置，驱动无法识别。还有一个场景：一台机器上同时装了 MySQL 5.7 和 8.x，5.7 的库没有全局时区问题，8.x 却报错。
解决：连接 URL 里加 serverTimezone 参数，两种写法都行——serverTimezone=Asia/Shanghai 或者 serverTimezone=GMT%2B8。前者语义更清晰，推荐用这个。注意如果 URL 里已经带了别的参数，各个参数之间用 & 分隔，serverTimezone 前的那个参数末尾也要加 &。另外，可以在 MySQL 命令行执行 SET GLOBAL time_zone = '+08:00'，一劳永逸，但要注意这条命令重启 MySQL 后可能失效，需要在配置文件里写 default-time-zone。
5.4 借阅日期边界问题：SimpleDateFormat 线程不安全与“差一天”陷阱
现象：还书时计算逾期天数，偶尔出现“明明昨天是截止日，今天还却算了 2 天罚款”的诡异结果；或者列表页的日期格式对不上。
原因：第一类问题是 SimpleDateFormat 在多线程环境下不是线程安全的，Swing 的事件分发线程和数据库查询线程同时调用同一个 SimpleDateFormat 实例，解析出来的日期就会错乱。第二类问题是直接用 java.util.Date 计算时间差，Date 包含时分秒，DATEDIFF 只算自然日，两者混用就出现边界偏差。
解决：统一用 LocalDate 处理日期，数据库 DATE 类型映射到 LocalDate，DATEDIFF 只比较日期部分。代码里不要 new Date() 然后手动格式化再解析，绕一圈只会增加出错面。如果项目里要显示当前日期，用 LocalDate.now() 配合 DateTimeFormatter，线程安全且不会踩“差一天”。
5.5 演示环境没有 MySQL 服务：内置 H2 切换的后悔药方案
现象：答辩现场的电脑没有安装 MySQL 服务，或者 MySQL 服务起不来，系统打开就报连接失败。课程设计演示最怕这种环境问题——代码逻辑没问题，但数据库连不上，直接没法演示。
原因：Swing 桌面应用依赖外部 MySQL 服务，这是架构上的固有短板。现场不能装数据库，或者装了但服务启动失败，应用就瘫了。
解决：有一个成本不高的后悔药方案——在代码里做一个数据库类型切换，用 H2 数据库的 MySQL 兼容模式兜底。H2 是一个纯 Java 的内嵌数据库，jar 包才两兆多，随应用一起走，不需要安装服务。
# db.properties 配置里加一个开关，默认用 mysql，现场出问题切 h2 db.type=mysql # db.type=h2// DBUtil 里根据配置决定加载哪个驱动和 URL if ("h2".equals(dbType)) { // H2 的 MySQL 兼容模式，支持大部分 MySQL 语法 url = "jdbc:h2:~/library_db;MODE=MySQL;DATABASE_TO_LOWER=TRUE"; } else { url = "jdbc:mysql://localhost:3306/library_db?..."; }这个方案的价值在于，切换之后大部分建表 SQL 和基本查询不需要改，H2 的 MySQL 兼容模式能跑通。但有两个坑要提前知道：第一，H2 对 DATEDIFF 的支持跟 MySQL 不完全一样，逾期计算这类 SQL 要在交付前用 H2 模式实测一遍；第二，H2 是内嵌数据库，数据只在当前机器上，换机器要重新跑初始化脚本。这个方案是备胎，不是主方案，主方案还是保证现场 MySQL 可用。
6. 让课程设计从“能跑”到“能答辩”：三个加分技巧与最终验证清单
6.1 用截图 + 操作路径整理 README，答辩讲解不卡壳
源码包交付出去，第一印象不是代码，而是 README。我见过太多人只丢一个 zip 包，里面代码、数据库脚本、界面截图混在一起，任何人打开都不知道从哪开始。建议 README 里固定写四块内容：运行环境要求（JDK 版本、MySQL 版本）、数据库初始化步骤（执行 SQL 脚本的命令或操作路径）、启动步骤（jar 怎么跑，或者 IDE 里怎么运行主类）、演示路径（登录什么账号、点哪个菜单、做什么操作）。
每一块配合截图。截图不要一屏塞满，要按“登录界面 → 主界面 → 借书操作 → 借阅记录 → 数据统计”这个顺序，每张图下面加一行说明。答辩现场屏幕可能很小，截图字号要放大，关键按钮用红圈标出来。这些截图同时也是答辩 PPT 的素材，一份工作做两处用。
6.2 演示时操作路径固定：同一台机器跑三遍再上
答辩演示最忌讳临场发挥，想到哪点到哪。我自己的习惯是固定一条演示路径，反复走到肌肉记忆：登录管理员 → 进入图书管理，按分类筛选记录 → 选一本书执行借出 → 切换到读者视角查看借阅记录 → 展示逾期列表和罚款金额 → 最后用统计图表收尾。这条路径覆盖了增删改查、事务完整性、聚合查询三个方面的展示，每个功能大约一分钟，总共控制在七八分钟内。
在固定路径之外，把所有演示账号、初始数据状态提前确认一遍。上次运行结束后的数据状态要恢复到初始状态——比如演示用的那本书如果被借出去了，借阅记录和库存数量跟 README 里的截图就对不上。解决办法是演示前重新跑一遍初始化脚本，或者做备份还原。
6.3 最终验证：在干净机器上从零跑一遍
交付之前最重要的验证，是找一台没配置过这个项目的干净环境，完全按照 README 的步骤从零开始走一遍。这个“干净环境测试”能暴露的坑比你想象得多：JDK 版本不对、MySQL 密码不是 root/123456、SQL 脚本漏执行一步、目录路径里有中文空格导致 jar 起不来。这些在自己开发机上永远不会触发，在验收/答辩机器上可能随时炸掉。
测试标准很简单：新建一个目录，把 zip 解压进去，照着 README，不碰代码、不碰配置，按步骤完成环境准备、数据库初始化、启动应用、走通固定演示路径，全程录屏。这个过程如果超过十五分钟，说明交付包的易用性还有问题，要回头优化 README——而不是优化代码。
做课程设计这些年，我最大的教训是：代码写得好，不如交付包做得好。评分老师不会花半小时逐行读你的源码，但会在五分钟内判断“这个系统是不是真的跑通了”“作者有没有把细节想清楚”。一个无错运行的初始化脚本、一段事务完整的借还代码、一张被讲透的表结构图，比十个华而不实的功能都值。把交付包当成产品来做，把 README 当成答辩讲稿来写，这门课的收获远不止一个高分。希望这些拆解能帮到你，尤其是那些第一次做 Java 课程设计、还在为表结构和事务发愁的同学。
本文还有配套的精品资源，点击获取
