简介：面向高校计算机专业学生与Java初学者的一套图书馆管理系统实训项目完整工作区，围绕图书信息管理、读者信息维护、借阅与归还、图书查询统计等核心模块展开，可用于课程设计、实训答辩以及Java面向对象综合练习。压缩包共1988个文件、约6MB，以676个xmi建模文件、128个class字节码、30个java源码以及27个xml配置、27个launch运行配置为主，另含prefs偏好设置与log运行日志，能较完整地还原项目在IDE中的工程结构与建模过程。已有230人学习下载。读者可以从中获得可导入IDE直接运行的工程骨架、数据库表设计与借阅业务的实现参考，也可以结合借阅记录、权限校验、异常处理等模块理解MVC分层思路，还能对照xmi模型梳理实体关系，按需裁剪后复用到自己的实训作业中。

1. 图书馆管理系统的真正难点，在借阅柜台那一下

实训任务发下来，多数人看到「图书馆管理系统」六个字的第一反应是：一张图书表的增删改查，两三天能收工。真坐到电脑前第三天，卡住的地方往往不是界面，而是借阅柜台那一下——两个窗口同时点「借出」，库存从 1 变成 -1；读者还书时手抖点两下，可借数超过了总藏书量；应还日期拿 Date 加 30 天，碰上跨月或闰年就算错一天。图书馆 图书 管理系统这道题，考的是业务规则能不能被代码严格守住，窗体画得漂不漂亮反而是次要的。

这套方案按 Java 实训的交付标准来搭：分层结构、五张核心表、借阅事务、罚金计算、验收用例。做毕设或课设的同学可以直接照这套结构交作业，需要把它改造成 Web 版交付的从业者，也能拿它当业务底稿。下面从需求拆解一路讲到答辩现场怎么自证系统真的能跑。

2. 需求拆解与技术选型：三层架构怎么切分六条业务线

2.1 把「图书管理」拆成六条业务线和一个角色矩阵

「图书管理系统」是个筐，什么都能往里装。不先切边界，最后一定做成一个所有按钮都堆在主窗体上的大杂烩。我一般按业务动作拆成六条线，每条线对应一组界面和一组服务方法：

1. 登录与鉴权：账号、密码、角色、会话状态。管理员能进全部菜单，馆员只能进借还和查询。
2. 图书档案：入库、修改、下架、分类维护、按 ISBN 查重。
3. 读者档案：办证、修改联系方式、挂失、注销、借阅上限与借期配置。
4. 借阅与归还：核心线。谁借了什么、什么时候该还、还了没有、罚了多少钱。
5. 续借与超期处理：续借次数上限、超期名单导出、罚金结算。
6. 查询统计：按书名/作者/ISBN 模糊检索、按分类统计藏书量、按月份统计借阅次数。

角色矩阵用一张表定死，比在代码里到处写if (role.equals("admin"))靠谱得多：

参数配置这一栏最容易被忽略。借期 30 天、上限 5 本、每天罚 0.1 元，这三个数一旦写死在 Java 常量里，验收时老师问一句「教师借期能不能长一点」，就得改代码重编译。正确的做法是放进t_config表或config.properties，启动时加载成内存对象，界面上给出修改入口。

2.2 为什么是 Java SE + Swing + JDBC，而不是直接上框架

技术选型不是越新越好，是看这门课/这个交付要考什么。实训任务的考核点集中在 Java 语言本身：集合、异常、IO、多线程、JDBC、面向对象。上 Spring Boot 会把大量逻辑藏进注解和自动配置里，答辩时老师问「事务是怎么起的」，答「加了个 @Transactional 注解」是拿不到分的。

三条路线摆在一起对比：

这道题我建议走桌面版。理由有三条：Swing 省掉前端工程化，注意力能全放在业务规则上；手写 JDBC 逼着把事务边界想清楚，这份能力换到任何框架都通用；本机跑，答辩现场不依赖网络和服务器，少一个翻车源。JDK 用 8 或 17 都行，MySQL 用 5.7 或 8.0，驱动包mysql-connector-java记得和数据库版本对上。

如果后续要迁 Web 版，改动集中在ui包：把 Swing 窗体换成 Servlet 或 Controller，service和dao两层几乎原样搬过去。这也是分层的价值——换皮不换骨。

2.3 包结构与分层职责：UI 里出现一句 SQL 就是设计事故

包结构定成这样，后面所有代码都往这七个格子里放：

com.library ├── ui // 窗体、事件监听、输入校验提示 ├── service // 业务规则、事务边界、跨表编排 ├── dao // SQL 语句、结果集到实体的映射 ├── model // 实体类：Book、Reader、BorrowRecord、Admin ├── util // 数据库连接、日期工具、密码哈希 ├── config // 参数加载：借期、上限、罚金 └── App.java // 启动入口

调用方向单向：ui → service → dao，谁都不许反向调，ui不许 importjava.sql.*。这条规矩听起来死板，但它决定了你后期能不能改。举个最常见的场景：图书列表要加一列「当前可借」，如果列表是直接在窗体里拼 SQL 查的，这一列得改三处；如果走BookService.list()，改一处就行。

连接管理用一个工具类收口，所有 DAO 从它拿连接，禁止各自DriverManager.getConnection：

public final class DbUtil { private static String url; private static String user; private static String password; // 类加载时读一次配置，避免每次取连接都读文件 static { Properties p = new Properties(); try (InputStream in = DbUtil.class.getResourceAsStream("/db.properties")) { p.load(in); url = p.getProperty("jdbc.url"); user = p.getProperty("jdbc.user"); password = p.getProperty("jdbc.password"); Class.forName(p.getProperty("jdbc.driver")); } catch (Exception e) { throw new ExceptionInInitializerError("数据库配置加载失败：" + e.getMessage()); } } private DbUtil() {} /** 调用方负责 close()，推荐配合 try-with-resources 使用 */ public static Connection getConnection() throws SQLException { return DriverManager.getConnection(url, user, password); } }

db.properties外置的好处是换机器只改一个文件，不动代码：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/library?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.user=root jdbc.password=123456

连接串里那三个参数不是装饰：characterEncoding=utf8决定中文书名会不会变成问号，serverTimezone决定LocalDate存进去会不会差一天，useSSL=false让本机连接不弹警告。这三处是后面避坑章要反复提到的源头。

service层的方法签名统一抛SQLException和自定义的BizException，前者是系统故障，后者是业务拒绝（库存不足、超上限、读者证异常），界面层分开提示——「系统繁忙请重试」和「该读者已达借阅上限 5 本」给用户的感受完全是两回事。

3. 数据库设计：五张表撑起借阅、库存、罚金三条主线

3.1 表结构与建表语句

五张表：分类、图书、读者、借阅记录、账号。参数配置可以放第六张t_config，也可以走 properties，二选一，我倾向后者，省一次连库。

图书表的关键在total_copies和available_copies这一对字段。前者是馆藏总量，入库时定下就基本不动；后者是当前可借数，每借一次减一、每还一次加一。读者表的关键是max_borrow和borrow_days，不同类型读者给不同配额。

CREATE TABLE t_book ( id BIGINT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL, title VARCHAR(120) NOT NULL, author VARCHAR(60) NOT NULL, publisher VARCHAR(80), category_id INT NOT NULL, price DECIMAL(8,2) NOT NULL DEFAULT 0.00, total_copies INT NOT NULL DEFAULT 1, available_copies INT NOT NULL DEFAULT 1, status VARCHAR(16) NOT NULL DEFAULT 'ON_SHELF', -- ON_SHELF / OFF_SHELF create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_isbn (isbn), KEY idx_title (title), CONSTRAINT ck_avail CHECK (available_copies >= 0 AND available_copies <= total_copies) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_borrow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, book_id BIGINT NOT NULL, reader_id BIGINT NOT NULL, borrow_date DATE NOT NULL, due_date DATE NOT NULL, return_date DATE NULL, status VARCHAR(16) NOT NULL DEFAULT 'BORROWED', -- BORROWED / RETURNED / OVERDUE renew_count INT NOT NULL DEFAULT 0, fine DECIMAL(8,2) NOT NULL DEFAULT 0.00, KEY idx_reader_status (reader_id, status), KEY idx_book_status (book_id, status), CONSTRAINT fk_borrow_book FOREIGN KEY (book_id) REFERENCES t_book(id), CONSTRAINT fk_borrow_reader FOREIGN KEY (reader_id) REFERENCES t_reader(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

t_reader除了常规的证件号、姓名、电话，多两个业务字段max_borrow（默认 5）和borrow_days（学生 30、教师 60）。t_admin存username、password_hash、salt、role四列，密码绝不存明文，具体做法在后一节讲。t_category就是 id + name，两级分类够用了，别一开始就上树形结构。

CHECK约束要 MySQL 8.0.16 以上才真正生效，5.7 会静默忽略。不确定版本就靠代码守，别指望数据库。

3.2 冗余一个 available_copies，是权衡不是偷懒

有人会问：可借数量为什么不直接SELECT COUNT(*) FROM t_borrow WHERE book_id=? AND status='BORROWED'算出来，非要冗余一列？因为借阅记录是只增不删的历史表，一个热门书三年下来几百条记录，每次打开图书列表都要为每一行做一次子查询，页面会肉眼可见地卡。冗余字段是常规做法，代价是一致性必须靠代码守，一旦某次事务回滚没处理好，库存就会和实际借出数对不上。

所以配套要有一个对账 SQL，做成管理员菜单里的「数据校验」按钮，随时能查：

-- 找出库存与实际借出数不一致的图书，正常应返回 0 行 SELECT b.id, b.title, b.total_copies, b.available_copies, COUNT(r.id) AS borrowed FROM t_book b LEFT JOIN t_borrow r ON r.book_id = b.id AND r.status IN ('BORROWED', 'OVERDUE') GROUP BY b.id, b.title, b.total_copies, b.available_copies HAVING b.available_copies <> b.total_copies - COUNT(r.id);

这条 SQL 在开发阶段能帮你抓出大部分事务 bug，比一行行点界面快得多。我一般在每次改完借还逻辑后都跑一遍，返回空结果才算过关。

3.3 约束与索引：能让数据库拒的，就别只靠 Java 判断

三层校验各管一段：界面层管格式（ISBN 不能为空、手机号 11 位），Service 层管业务（库存够不够、读者有没有超限），数据库管底线（唯一、非空、外键、CHECK）。只做前两层，一旦有人直接连库改数据，脏数据就进去了。

索引就建三个：t_book上title的普通索引（模糊检索用，前置通配符%java%用不上索引，但前缀匹配java%能用）；t_borrow上(reader_id, status)联合索引（查某读者当前在借几本，走这条最快）；(book_id, status)同理。别给每个字段都建索引，写时会拖慢，实训规模的数据量下多余的索引纯属负担。

外键用RESTRICT而非CASCADE。图书下架走status='OFF_SHELF'逻辑删除，物理删除会连带把历史借阅记录清掉，统计报表直接缺行——这是验收时最容易被追问的一个点。

4. 核心业务实现：借阅事务、归还幂等与超期罚金

4.1 借阅流程的事务边界与行锁

一次借阅要动两张表：往t_borrow插一条记录，把t_book的可借数减一。这两步必须同生共死，所以setAutoCommit(false)开事务，任何一步失败整体回滚。事务边界放在 Service 层，不放在 DAO——DAO 只负责单条 SQL，它不知道这次操作还牵扯到别的表。

并发问题是这道题的分水岭。两个借阅窗口同时操作同一本书，都读到「可借 1 本」，都判断通过，都去减一，结果库存变成 -1，两个人各借走一本。解决办法是在读图书那一行时加排他锁：

public void borrow(long bookId, long readerId) throws SQLException, BizException { Connection conn = DbUtil.getConnection(); try { conn.setAutoCommit(false); // 事务开始 // 1. 锁住图书行：SELECT ... FOR UPDATE，后到的事务在这里排队 Book book = bookDao.lockById(conn, bookId); if (book == null || !"ON_SHELF".equals(book.getStatus())) { throw new BizException("图书不存在或已下架"); } if (book.getAvailableCopies() <= 0) { throw new BizException("《" + book.getTitle() + "》已全部借出"); } // 2. 读者状态与借阅上限校验 Reader reader = readerDao.getById(conn, readerId); if (reader == null || !"NORMAL".equals(reader.getStatus())) { throw new BizException("读者证状态异常，无法借阅"); } int current = borrowDao.countActive(conn, readerId); if (current >= reader.getMaxBorrow()) { throw new BizException("已达借阅上限 " + reader.getMaxBorrow() + " 本"); } // 3. 写借阅记录，应还日期由读者类型决定 LocalDate today = LocalDate.now(); LocalDate due = today.plusDays(reader.getBorrowDays()); borrowDao.insert(conn, bookId, readerId, today, due); // 4. 扣库存：带条件更新，影响行数为 0 说明被别的线程抢先了 int affected = bookDao.decreaseAvailable(conn, bookId); if (affected != 1) { throw new BizException("库存不足，借阅失败"); } conn.commit(); // 全部成功才提交 } catch (SQLException | BizException e) { conn.rollback(); // 任一步失败整体回滚 throw e; } finally { conn.setAutoCommit(true); conn.close(); } }

配套的两条 SQL，注意第二句的条件：

// BookDao.lockById：加行锁读，必须在事务内调用 String sql = "SELECT id, title, status, total_copies, available_copies, price " + "FROM t_book WHERE id = ? FOR UPDATE"; // BookDao.decreaseAvailable：条件更新，把并发判断交给数据库 String sql = "UPDATE t_book SET available_copies = available_copies - 1 " + "WHERE id = ? AND available_copies > 0";

FOR UPDATE和WHERE available_copies > 0两道保险叠着用不是浪费。前者防同一行被两个事务同时读到旧值，后者在锁失效（比如有人忘了开事务）时兜底，让更新影响行数变成 0，代码就能感知到异常。这段逻辑写对之后，把库存改成 1 本、开两个客户端同时借，只能成功一个，库存归 0。

BizException是自定义的受检异常或运行时异常，专门承载业务拒绝信息。别用RuntimeException("失败")一把梭，界面层没法区分该弹红色警告还是提示重试。

4.2 归还与续借：幂等判断怎么写

归还要处理的核心是重复提交。读者或馆员手快点两下「确认归还」，如果代码只会无脑执行，库存就加两次，最终超过馆藏总量。所以第一步先查记录状态，第二步更新时再带一次状态条件，双保险：

public BigDecimal returnBook(long borrowId) throws SQLException, BizException { Connection conn = DbUtil.getConnection(); try { conn.setAutoCommit(false); BorrowRecord r = borrowDao.lockById(conn, borrowId); // 同样加行锁 if (r == null) { throw new BizException("借阅记录不存在"); } if ("RETURNED".equals(r.getStatus())) { throw new BizException("该记录已归还，请勿重复操作"); // 幂等拦截 } LocalDate back = LocalDate.now(); BigDecimal fine = FineCalculator.calc(r.getDueDate(), back, r.getBookPrice()); // 更新语句自带状态条件，影响行数必须是 1 int affected = borrowDao.markReturned(conn, borrowId, back, fine); if (affected != 1) { throw new BizException("归还状态已变更，请刷新后重试"); } bookDao.increaseAvailable(conn, r.getBookId()); conn.commit(); return fine; } catch (SQLException | BizException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); conn.close(); } }

-- BorrowDao.markReturned：状态条件保证只有第一次执行会生效 UPDATE t_borrow SET status = 'RETURNED', return_date = ?, fine = ? WHERE id = ? AND status IN ('BORROWED', 'OVERDUE')

续借的逻辑简单一些，但要卡两个上限：续借次数不超过 2 次，且新应还日期从「原应还日期」往后推，不是从今天推。从今天推会让读者通过反复续借无限延期，这是业务上的漏洞。

4.3 超期罚金与日期计算：全部换成 LocalDate

罚金规则定成：逾期每天 0.1 元，罚金上限为书价的 50%，避免一本几十块的书罚出天价。日期一律用java.time.LocalDate，不用java.util.Date——后者带时分秒，算天数差要先归一化，跨时区和闰年特别容易出错。

public final class FineCalculator { private static final BigDecimal PER_DAY = new BigDecimal("0.10"); // 每日罚金 private static final BigDecimal CAP_RATE = new BigDecimal("0.50"); // 罚金上限比例 private FineCalculator() {} /** * @param due 应还日期 * @param back 实际归还日期 * @param price 图书定价，用于计算罚金上限 */ public static BigDecimal calc(LocalDate due, LocalDate back, BigDecimal price) { long days = ChronoUnit.DAYS.between(due, back); if (days <= 0) { return BigDecimal.ZERO; // 未超期或当天归还 } BigDecimal fine = PER_DAY.multiply(BigDecimal.valueOf(days)); BigDecimal cap = price.multiply(CAP_RATE).setScale(2, RoundingMode.HALF_UP); return fine.min(cap).setScale(2, RoundingMode.HALF_UP); } }

ChronoUnit.DAYS.between直接给出两个LocalDate之间的整天数，跨月、跨年、闰年都不用自己判断。金额一律BigDecimal，别用double——0.1 在二进制里是无限循环小数，累加十次会得到 0.9999999999999999，账面上差一分钱也是错。

超期状态靠一个定时任务或启动时扫描刷新：把due_date < CURDATE()且status='BORROWED'的记录改成OVERDUE。实训规模下不需要真起定时器，程序启动时执行一次UPDATE就够，但你要能说清楚这个设计意图。

4.4 分页查询与模糊检索

图书列表一定要分页，一页 20 条。数据量小的时候不分页看不出问题，答辩时导入一份几百本的测试数据，一次性查全表再往 JTable 里塞，界面会明显卡顿。

-- 分页 + 模糊检索，? 依次是 keyword、keyword、keyword、limit、offset SELECT id, title, author, isbn, available_copies, total_copies, status FROM t_book WHERE status = 'ON_SHELF' AND (title LIKE ? OR author LIKE ? OR isbn LIKE ?) ORDER BY id DESC LIMIT ? OFFSET ?

Java 侧拼参数时注意通配符要自己加，并且对用户输入里的%和_做转义，否则输入一个%就变成全表匹配：

String kw = "%" + keyword.replace("\\", "\\\\") .replace("%", "\\%") .replace("_", "\\_") + "%"; int offset = (page - 1) * pageSize; // ps.setString(1, kw); ps.setString(2, kw); ps.setString(3, kw); // ps.setInt(4, pageSize); ps.setInt(5, offset);

另配一条SELECT COUNT(*)用同样的WHERE条件算总数，用来生成页码。两条 SQL 的条件必须完全一致，否则会出现「显示 3 页但翻到第 3 页是空列表」的尴尬。条件复杂时用StringBuilder拼一个公共的 where 片段，两处复用。

5. 避坑与排查：五个最容易在演示当天翻车的点

5.1 借阅与库存相关的三个坑

坑一：可借数量变成负数，或者 5 本库存借出 6 本。

现象是连续点两次借阅按钮，或者开两个窗口操作同一本书，库存字段出现 -1。原因是「先查再改」之间没有锁，两个事务读到同一份旧值，各自判断「还有库存」，然后各自减一。解决方式是 4.1 节那套组合：事务内SELECT ... FOR UPDATE锁行，扣减语句带AND available_copies > 0并检查影响行数，表上再挂CHECK约束兜底。三样缺一样都可能漏。

坑二：还一本书，库存加了两次，可借数超过馆藏总量。

现象是读者点「确认归还」时手抖或界面卡顿重复提交，available_copies从 3 变成 5，而total_copies只有 4。原因是更新语句没有状态条件，同一行被更新了两次。解决办法是把状态判断写进 SQL 的WHERE里，status IN ('BORROWED','OVERDUE')，影响行数等于 1 才去加库存；界面上的归还按钮点击后立即置灰，防住第一层。

坑三：删掉一本旧书，历史借阅统计里那几条记录凭空消失。

现象是管理员在图书档案里点删除，之前的借阅记录跟着没了，月度报表数字对不上。原因是用了物理DELETE，外键又是ON DELETE CASCADE。正确做法是status改成OFF_SHELF做逻辑下架，下架后不出现在借阅列表的检索结果里，但历史记录和外键都保留。外键声明改成RESTRICT，从数据库层面禁止误删。

5.2 环境、编码与演示环节的两个坑

坑四：本机跑得好好的，换台机器书名全变成问号。

现象是图书入库时中文正常，换一台电脑打开，列表里全是???。原因有两个可能：连接串没写characterEncoding=utf8，或者建表时没指定CHARSET=utf8mb4，用了服务器默认的 latin1。排查顺序是先看表结构SHOW CREATE TABLE t_book，确认末尾是utf8mb4；再看db.properties里三个参数是否齐全。两处都对了还乱码，检查 IDE 的文件编码是不是 UTF-8。

坑五：答辩现场双击 jar 包，报 Communications link failure。

现象是在自己电脑上稳如泰山，到教室打开就连接失败。原因通常是配置写死了本机路径、依赖本机已启动的 MySQL 服务、或者数据库里只有空表没有演示数据。规避方式是三件事：配置外置成db.properties并放在 jar 同级目录；准备一份init.sql，包含建表语句和至少 30 本图书、10 个读者、若干条借阅记录的种子数据，现场导入；提前 30 分钟到场，在目标机器上完整跑一遍借书—还书—超期三条链路。演示环境的问题，代码写得再好也救不回来。

6. 验收与答辩：用一张用例表证明系统真的能跑

功能做完不等于能交。我习惯在提交前跑一遍固定用例，逐条勾，勾不满就不提交。这套用例覆盖了业务规则里所有「边界」，也是老师最爱抽查的地方：

TC-08 这条最值得在答辩时主动演示。开两个客户端，把库存调成 1，同时点借阅，一个成功一个提示库存不足，比任何口头解释都有说服力。老师问「你怎么保证并发安全」，直接跑一遍，再指一下FOR UPDATE和条件更新那两行代码。

答辩常见的问题还有几个，提前准备好答案：为什么库存要冗余字段（见 3.2，讲清楚用空间换查询效率，代价靠事务和对账 SQL 守住）；事务边界为什么在 Service 层（DAO 只管单条 SQL，跨表编排属于业务）；如果改成 Web 版要动哪里（只换ui包，service/dao原样迁）；密码为什么不能明文存（t_admin存password_hash和salt，用PBKDF2WithHmacSHA256加盐迭代，登录时用同样盐值算一遍比对，别用 MD5）。

那套用例表和init.sql，从那以后我每次带实训都要求学生在提交前，把数据库删干净、用脚本从零重建、再逐条跑一遍。跑不通的，问题八成在环境不在代码；跑得通的，答辩时心里有底。希望帮到你。

本文还有配套的精品资源，点击获取