简介面向计算机专业毕业设计的JAVA图书馆书库管理系统资源以论文加源代码形式呈现适合JAVA学习者、毕业生及初入职场的开发人员作为课程设计与项目实战参考。系统采用JDBC实现数据库交互Servlet/JSP构建Web展示层并运用MVC模式分离业务逻辑与界面覆盖图书查询、借阅归还、续借、卡片管理、用户管理等典型书目管理流程同时包含管理员与普通读者的角色权限控制。压缩包内共61个文件以15个java源文件与27个class编译文件为主配套1篇图书馆书库管理系统论文doc、1个mdb数据库文件、1个jar可运行包、1个jcp工程配置另含9个gif界面素材和txt/mf等说明文件整包仅606KB便于快速下载与本地环境部署研究。资源已有775人学习下载适合用较短时间对照源码梳理系统设计全貌。通过这套项目读者可获得可运行的图书馆管理系统工程与论文写作参考既能用于毕业设计文档撰写也能借助项目源码理解JDBC数据访问、窗体事件监听、数据库表关联、权限管理等实现细节并进一步了解异常处理、日志记录以及本地环境部署的完整思路。1. 这类课设每年都有人做它到底难在哪“JAVA图书馆书库管理系统设计(论文源代码)”这个标题每年都出现在课程设计和毕业设计的题目列表里。乍一看它就是标准的图书、读者、借阅三张表的增删改查跑通就能交付。但真正动手做过的人都知道这套系统最花时间的不是 CRUD而是“借书—还书”这条状态链路一本书能不能借出取决于它当前在哪个书库、在库余量还剩多少、读者有没有超期未还任何一步判断失误演示现场就会穿帮。这篇笔记按“拆需求—建表—写核心流程—部署避坑—答辩验证”的顺序把一条完整能落地的路径讲清楚。适合正在选题、准备从零搭一个可运行系统的开发者也适合想把老 JSP 项目迁移到 Spring Boot 的读者。2. 先拆系统再选型图书馆业务的模块清单与两条技术路线的取舍2.1 模块拆解五张表对应五组页面先把边界画清楚图书馆书库管理系统业务上就四件事管书、管人、管借还、管统计。往下拆就得到下面这些模块和对应的数据表、页面。开发前一定要把模块边界画清楚不然后面加需求时表结构会改到想哭。模块核心功能涉及数据表关键页面图书管理图书入库、修改、下架、按书名/作者/ISBN 检索book图书列表、新增/编辑图书分类管理图书分类维护category分类列表读者管理读者信息维护、借阅额度查看reader读者列表、新增/编辑读者借阅管理借书、还书、续借、超期查询borrow_record借阅登记、还书登记、超期列表统计与报表在库量、借出量、热门图书book / borrow_record统计面板系统管理管理员登录与密码修改admin登录页、修改密码为什么这样拆核心在于“借阅”这个动作在数据模型上是典型的多对多一个读者可以借多本书一本书也能被多个读者先后借阅所以必须拆出一张中间表 borrow_record 来记录每次借还。分类和图书是 1 对多分类表要优先建否则后面图书表加外键时又要回头补数据。另一个容易漏的细节是每本书的“馆藏总量”和“在库可借量”直接冗余在 book 表里而不是每次查询时现算。列表页每页都要显示几十本书的在库量如果每行都去 count 借阅记录数据量稍大页面就会明显变慢这是做管理信息系统最基础的冗余换性能思路。模块清单定完后不要急着写代码。先把每个页面要展示哪些字段列出来比如图书列表需要“书名、作者、分类、在库量、书架位置”新增图书表单需要“ISBN、书名、作者、出版社、出版日期、分类、馆藏总量、书架位置”。这一步做完后面建表、写页面、写论文里的需求分析都有现成素材。2.2 两条技术路线JSP Servlet 与 Spring Boot怎么选不后悔这个题目常见的实现路线有两条。一条是传统的 JSP Servlet JDBC 另一条是 Spring Boot MyBatis或 JPA。两条路线各有明确的适用场景别听别人说“老技术过时了”就一票否决也别觉得“框架越新越好”硬上微服务。对比项JSP Servlet JDBCSpring Boot MyBatis上手难度低概念贴近课本中依赖和配置要先理解开发效率低JDBC 样板代码多高自动配置省大量时间答辩亮点分层结构直观好讲清楚主流技术栈能聊治理和部署典型坑编码、连接池、Tomcat 配置依赖冲突、版本兼容、Lombok推荐场景课程设计、想搞懂 Web 底层毕业设计、想封装完整交付物我的常见做法是课设选 JSP 路线因为老师要看到你对请求响应、会话、JDBC 的掌握毕设选 Spring Boot 路线因为需求更完整开发周期也更长框架能帮你把精力省给业务逻辑和论文。如果时间只剩两周别犹豫直接 Spring Boot Thymeleaf或内嵌 JSP Bootstrap前端不搞前后端分离这是交付效率最高的组合。注意前后端分离Vue Spring Boot在这个题目里属于锦上添花不是刚需除非你已经熟练 Vue否则别给自己加戏。2.3 最小工程骨架从依赖到目录结构的落地参考以 Spring Boot 路线为例一个最小可运行的项目结构大概长这样src/main/java/com/example/library ├── LibraryApplication.java ├── controller │ ├── LoginController.java │ ├── BookController.java │ ├── ReaderController.java │ └── BorrowController.java ├── service │ ├── BookService.java │ ├── ReaderService.java │ └── BorrowService.java ├── mapper │ ├── BookMapper.java │ ├── ReaderMapper.java │ └── BorrowRecordMapper.java ├── entity │ ├── Book.java │ ├── Reader.java │ ├── BorrowRecord.java │ └── Admin.java └── config └── WebConfig.java src/main/resources ├── application.yml └── mapper ├── BookMapper.xml ├── ReaderMapper.xml └── BorrowRecordMapper.xml这个分层不是形式主义。controller 只做参数接收和页面跳转业务判断全部放到 serviceSQL 写在 mapper.xml。答辩时老师问“借书超期怎么判断”你要能一层层指给他看页面请求进 BorrowController判断逻辑在 BorrowService 的 returnBook 方法SQL 在 BorrowRecordMapper.xml。如果全写在 controller 里代码短的时候看不出问题借还逻辑一复杂就变成大泥球。pom.xml 里最关键的依赖就这几个dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependenciesSpring Boot 2.7.x 配合 mybatis-spring-boot-starter 2.3.x 是一组很稳的组合不要追新换 spring boot 3.x除非你的 JDK 已经升到 17 并且愿意处理 jakarta 命名空间迁移。Lombok 用来省去实体类的 getter/setter但如果你的答辩老师对“不知道 Lombok 是什么”有风险也可以不引入手写 getter/setter 也就多几分钟。application.yml 里最值得注意的配置是数据源连接串server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/library?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: trueurl 里的参数每一个都有用useUnicode 和 characterEncoding 保证中文不乱码serverTimezoneAsia/Shanghai 解决 MySQL 8.x 驱动在连接时对时区的强制校验。map-underscore-to-camel-case 让数据库里的 create_time 自动映射成实体类的 createTime 字段省去大量手写 resultMap。记住这三件事建库用 utf8mb4、连接串带编码参数、全局开启驼峰映射中文乱码问题基本能消灭在配置层。3. 数据库设计与建表 SQL五张表的结构、索引与关键字段3.1 从业务反推表结构分类、图书、读者、借阅、管理员缺哪张都不行表结构设计别一上来就写 CREATE TABLE先想数据是怎么流动的。一本书属于某个分类一个读者可以借多本书一本书能被多个读者先后借阅这是典型的多对多关系必须拆出一张中间表 borrow_record 来记录每次借还。分类、图书、读者、借阅、管理员这五张表就是这个系统的全部数据骨架缺一张都会在某个功能上卡住。逐张说字段。category 表只需要 id、name、create_timename 要加唯一约束避免“文学”和“文学 ”这种重复分类混进去。book 表是字段最多的一张isbn、title、author、publisher、publish_date、category_id、total_stock、available_stock、shelf_location、status、create_time、update_time。其中 total_stock 和 available_stock 是冗余设计前文说过这是为了列表页查询性能。shelf_location 存“A-3-2”这种书架定位别小看这字段书库管理系统在真实场景里最常被问的就是“这本书放在哪”。reader 表除了基础信息要有一个 max_borrow_count 字段控制每人最多借几本这比在代码里写死数字合理得多。borrow_record 表是核心字段有 book_id、reader_id、borrow_time、due_time、return_time、status、fine_amount。admin 表极简username、password、real_name 就够。这里有一个设计决策要提前定图书的“可借状态”是用 book.status 表达还是用 available_stock 数字表达我的习惯是两者都保留。status 表达“这本书是否在架”比如缺损下架available_stock 表达“此刻能借出几本”。下架书不参与借阅在架书才扣减库存两个字段各管一件事业务语义才清晰。3.2 建表 SQL 与参数选择字段类型、默认值、唯一键一次到位下面是这套系统最常用的建表 SQL按先分后主的顺序执行CREATE TABLE category ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 分类ID, name VARCHAR(50) NOT NULL UNIQUE COMMENT 分类名称, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图书分类表; CREATE TABLE book ( id INT AUTO_INCREMENT PRIMARY KEY, isbn VARCHAR(20) NOT NULL COMMENT ISBN编号, title VARCHAR(200) NOT NULL COMMENT 书名, author VARCHAR(50) NOT NULL COMMENT 作者, publisher VARCHAR(100) COMMENT 出版社, publish_date DATE COMMENT 出版日期, category_id INT NOT NULL COMMENT 分类ID, total_stock INT NOT NULL DEFAULT 0 COMMENT 馆藏总量, available_stock INT NOT NULL DEFAULT 0 COMMENT 在库可借量, shelf_location VARCHAR(50) COMMENT 书架位置如A-3-2, status TINYINT NOT NULL DEFAULT 1 COMMENT 1在架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_book_category FOREIGN KEY (category_id) REFERENCES category(id), INDEX idx_book_title (title) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图书表; CREATE TABLE reader ( id INT AUTO_INCREMENT PRIMARY KEY, reader_no VARCHAR(20) NOT NULL UNIQUE COMMENT 读者证号, name VARCHAR(50) NOT NULL COMMENT 姓名, phone VARCHAR(20) COMMENT 联系电话, max_borrow_count INT NOT NULL DEFAULT 5 COMMENT 最大借阅量, status TINYINT DEFAULT 1 COMMENT 1正常 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT读者表; CREATE TABLE borrow_record ( id INT AUTO_INCREMENT PRIMARY KEY, book_id INT NOT NULL COMMENT 图书ID, reader_id INT NOT NULL COMMENT 读者ID, borrow_time DATETIME NOT NULL COMMENT 借出时间, due_time DATETIME NOT NULL COMMENT 应还时间, return_time DATETIME DEFAULT NULL COMMENT 实际归还时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0借出 1已还 2逾期未还, fine_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 罚款金额, CONSTRAINT fk_br_book FOREIGN KEY (book_id) REFERENCES book(id), CONSTRAINT fk_br_reader FOREIGN KEY (reader_id) REFERENCES reader(id), INDEX idx_br_status (status), INDEX idx_br_reader (reader_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT借阅记录表; CREATE TABLE admin ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(30) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(64) NOT NULL COMMENT 建议存SHA-256哈希, real_name VARCHAR(50) COMMENT 姓名, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT管理员表;逐条说明关键参数。字符集用 utf8mb4 而不是 utf8因为 MySQL 的 utf8 最多存 3 字节遇到 emoji 或生僻字会直接报错utf8mb4 是完整 UTF-8。引擎指定 InnoDB 是因为它还债必需事务和外键。MyISAM 不支持事务借书时要同时完成“插入借阅记录”和“扣减库存”如果不是在一个事务里执行中间任何一步失败都会让数据对不上账。金额字段用 DECIMAL(10,2) 而不是 FLOAT 或 DOUBLE二进制浮点数算钱会有 0.10.2 不等于 0.3 的问题存款和罚款都不能容忍这种误差。时间字段用 DATETIME不要用 TIMESTAMP 当主要业务时间。TIMESTAMP 有 2038 年上限虽然离现在还远但答辩时老师问“你有考虑过时间字段的边界吗”这是很好的加分素材。update_time 用 ON UPDATE CURRENT_TIMESTAMP 自动维护修改 book 表任何字段时这个时间自动刷新省去在代码里手动 set 的步骤。唯一键和外键的选择有几个细节。reader_no 和 category.name 用 UNIQUE 约束是合理的isbn 不要加 UNIQUE因为同版次的图书可能有多个 ISBN 变体实际业务中 ISBN 更应该当普通索引用。外键字段上 MySQL 会自动创建索引所以 fk_br_book 和 fk_br_reader 不需要手动重复建索引但 status 这种高频查询条件需要单独建 idx_br_status因为超期列表页几乎天天点。我还习惯给 title 建普通索引虽然 LIKE %关键字% 用不上它但 LIKE 关键字% 前缀查询能受益并且论文里写“已对高频查询字段建立索引”需要真有这个索引撑腰。3.3 借阅记录的两个设计原则只改状态不物理删除、超期用状态位表达很多新手会在“删除一条借阅记录”时直接把行 DELETE 掉这是书库系统最常见的翻车现场。借阅记录一旦物理删除这本书的在库量就永远找不回来——available_stock 比 total_stock 少一本又说不出少在哪因为记录没了。正确做法是把 status 从 0 改为 1return_time 写入实际归还时间保留完整历史。这在结课报告里可以单独写一小节“数据完整性设计”也是论文里数据字典部分的好素材。超期状态怎么表达我的方案是 borrow_record.status 用 0 表示借出未还且未超期2 表示借出且已超期1 表示已还。为什么不每次都靠比较 due_time 和 NOW() 来临时算因为“逾期未还”是超期列表页的主查询条件纯靠计算无法走索引数据量一上来页面就慢。做法是在业务层加一个定时任务每天扫描一次 due_time NOW() AND return_time IS NULL 的记录把 status 置为 2。课设阶段不要求你完整实现定时任务但答辩被问到“超期怎么判定”时你递出这个方案比说“在页面里 if 判断”高一档。4. 借书还书核心代码事务、状态判断与并发防重4.1 借书流程先校验后落库每一步都不能省借书是整套系统里业务规则最密集的操作。借书前必须依次确认读者存在且状态正常图书存在且在架在库余量大于 0读者当前借阅数没达到上限读者没有未归还的同名书。任何一步不满足都要中断操作并把原因明确抛给前端页面。下面是按 Spring Boot MyBatis 风格写的 BorrowService 核心方法public void borrow(Long bookId, Long readerId) { Reader reader readerMapper.selectById(readerId); if (reader null || reader.getStatus() 0) { throw new BusinessException(读者不存在或已停用); } Book book bookMapper.selectForUpdate(bookId); if (book null || book.getStatus() 0) { throw new BusinessException(图书不存在或已下架); } if (book.getAvailableStock() 0) { throw new BusinessException(此书暂无在库余量); } int activeCount borrowRecordMapper.countActiveByReader(readerId); if (activeCount reader.getMaxBorrowCount()) { throw new BusinessException(达到最大借阅数量请先归还部分图书); } int exists borrowRecordMapper.countActiveByBookAndReader(bookId, readerId); if (exists 0) { throw new BusinessException(你已借过此书请先归还); } LocalDateTime now LocalDateTime.now(); LocalDateTime due now.plusDays(30L); borrowRecordMapper.insert(new BorrowRecord(bookId, readerId, now, due)); bookMapper.decreaseStock(bookId); }逻辑说明这个方法把预约顺序设计成“查读者、锁书、校验、插记录、减库存”顺序不能乱。selectForUpdate 对应 SQL 是 SELECT ... FOR UPDATE它会把 book 表的这一行锁住直到事务提交或回滚。两个 count 查询分别在“读者借阅数量上限”和“同一读者重复借同一本书”上兜底这两个校验缺一个都会造成数据异常。dueTime 用 plusDays(30) 写死默认 30 天课设阶段可以接受但如果你想把借阅期限做成可配置就把天数放到 category 表或单独配置表里每本书按分类读取不同期限。4.2 还书流程状态更新、库存回补与超期罚款还书的逻辑相对简单但超期天数的计算边界要小心。核心代码如下public void returnBook(Long borrowRecordId) { BorrowRecord record borrowRecordMapper.selectById(borrowRecordId); if (record null || record.getStatus() 1) { throw new BusinessException(借阅记录不存在或已归还); } LocalDateTime now LocalDateTime.now(); BorrowRecord update new BorrowRecord(); update.setId(record.getId()); update.setStatus(1); update.setReturnTime(now); if (now.isAfter(record.getDueTime())) { long overdueDays Duration.between(record.getDueTime(), now).toDays(); if (overdueDays 0) { overdueDays 1; } BigDecimal fine BigDecimal.valueOf(overdueDays) .multiply(new BigDecimal(0.50)); update.setFineAmount(fine); } borrowRecordMapper.updateById(update); bookMapper.increaseStock(record.getBookId()); }参数说明Duration.toDays() 会向下取整导致“超期 1 小时”算成 0 天所以这里做了 overdueDays 为 0 时置 1 的兜底让超期不满一天也按一天算罚款。罚款单价 0.50 元写死在代码里可以但要记得在论文里把它归类为“系统参数”说明正式运营时应该提取到配置表。还书时先更新借阅记录状态再回补库存这两个操作依赖事务保证原子性如果更新状态成功但增加库存失败事务回滚后记录还是借出状态不会出现“书还了但库存没加”的账实不符。4.3 并发场景下的数据安全事务边界、行锁与乐观锁借书操作天然有并发问题两个管理员同时给不同读者办借同一本书如果代码没做防护最后一本书可能被借出两次。解决思路有三个层次。第一层是事务。borrow 方法要放在 Transactional 注解的方法里并且注意注解生效的条件Spring 的 Transactional 只有通过代理调用时才生效如果在同一个类里用 this.borrow(...) 调用别的方法事务会静默失效。这是 Spring 事务最经典的坑自调用让代理绕过了拦截器我见过不少人在这里查一整天才发现是调用方式问题。系动词交互时注入的是代理对象不是原始对象这也是为什么我习惯把事务边界放在 Service 的公开方法入口。第二层是行锁。bookMapper.selectForUpdate(bookId) 的 SQL 要显式加 FOR UPDATESELECT * FROM book WHERE id #{bookId} FOR UPDATE;加了 FOR UPDATE 之后同一时刻只有一个事务能读到这一行的最新数据并往下执行其余请求会在这一行上排队。注意锁的范围必须是 WHERE id 主键如果条件查出来多行或者没走主键索引MySQL 会锁住更大的范围甚至整张表那是性能事故。第三层是唯一索引兜底。在 borrow_record 表上加一个联合唯一索引比如 (book_id, reader_id, status) 的“当前未归还唯一”模式可以从数据库层面直接拒绝同一个人借同一本书两次的插入。前两层是应用层防护这一层是最后防线。课设阶段实现行锁已经足够出彩把唯一索引写进建表脚本并注释说明作用答辩老师会认为你真的考虑过边界情况。5. 部署运行避坑编码、时区、连接池五处常见问题5.1 Java 启动失败端口占用与版本不匹配现象启动时控制台报 Port already in use或者抛 UnsupportedClassVersionError。原因8080 端口被别的进程占了另一种情况是 JDK 版本和运行环境不匹配比如用 JDK 17 编译的 class 文件放到 JDK 8 环境跑。解决先看端口占用Windows 下用 netstat -ano | findstr 8080 查 PID再 taskkill /PID 进程号 /F。Linux/macOS 用 lsof -i:8080 查进程再 kill。版本问题优先确认 JAVA_HOME 指向的 JDK 版本Spring Boot 2.7 用 JDK 8 或 11 都稳别用 JDK 17 跑低版本框架。5.2 中文乱码三个环节逐层排查现象页面显示问号或者一串“ä½ å¥½”之类的乱码。原因中文乱码是整套系统里最常见的现象因为它有多个产生环节。Tomcat 的 URI 默认编码不是 UTF-8、MySQL 连接串没带 characterEncoding、数据库表本身是 latin1、页面没有声明响应编码任何一个环节断了都会在页面上现出原形。解决三层都要设。MySQL 连接串带上 characterEncodingutf8建表用 utf8mb4见第 3 章JSP 页面顶部加 % page contentTypetext/html;charsetUTF-8 %Controller 返回 JSON 时在 RequestMapping 上指定 produces application/json;charsetUTF-8。这三个地方都设对乱码基本绝迹。5.3 MySQL 连接报错时区与 SSL 参数导致的黑匣子现象控制台报 The server time zone value йʱ is unrecognized或者 SSL 连接警告刷屏。原因MySQL 8.x 的 JDBC 驱动在连接时要校验服务器时区本地 MySQL 默认时区是系统的 CST驱动认不出。SSL 握手是默认行为但本机开发根本不需要还会让启动日志变长看着心烦。解决连接串完整写法还是那句jdbc:mysql://localhost:3306/library?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueallowPublicKeyRetrievaltrue 是 MySQL 8.0 用 caching_sha2_password 插件时本地连接的常见补充参数不加可能报 Public Key Retrieval 异常。这个连接串是血泪经验换来的每次新建项目我都会直接复制过去省得再被时区问题卡一次。5.4 外键删除失败物理外键在管理端的前科现象删除一条分类时报 Cannot delete or update a parent row: a foreign key constraint fails。原因book 表通过 category_id 外键引用 category 表分类下还挂着书直接删分类违反了引用完整性约束。解决两种处理方式。一是在业务代码里先做检查分类下还有书就提示“请先移除该分类下的图书”二是在数据库设计上把物理外键去掉只在应用层维护引用关系分类有书也能删但会导致数据悬空不推荐。我的建议是保留物理外键删除前检查这既符合数据完整性原则答辩时也能说清楚为什么设计时保留了外键约束。5.5 Maven 依赖拉不下来换源后依然失败的隐藏原因现象mvn compile 卡住不动或持续报 Could not transfer artifact ... from/to central。原因中央仓库访问不稳定是最直接的因素但换完国内镜像源还有问题大概率是 settings.xml 没生效或者本地仓库里残留了 .lastUpdated 后缀的失败缓存文件Maven 看到这个文件会直接认为依赖“上次下载失败”拒绝重新尝试。解决先确认镜像源配到了真的生效的 settings.xml 里用 mvn help:effective-settings 检查当前生效配置再看本地仓库目录 ~/.m2/repository 下有没有 .lastUpdated 文件有就删掉对应目录重新构建最后加 mvn -U 强制检查更新。这三板斧解决 90% 的依赖下载问题剩下的就是公司网络限制这种环境问题。6. 进阶验证从“能跑”到“敢演示”的三步检查6.1 验证借还流程一条 SQL 查清三张表数据是否对得上系统跑通后先别急着点页面。用一条 SQL 验证逻辑层是否正确SELECT b.id, b.title, b.total_stock, b.available_stock, COUNT(br.id) AS borrowed_count FROM book b LEFT JOIN borrow_record br ON br.book_id b.id AND br.status IN (0, 2) GROUP BY b.id, b.title, b.total_stock, b.available_stock HAVING b.available_stock ! b.total_stock - borrowed_count;这条 SQL 查出“在库量”和“借出数量”对不上的书。如果结果不为空说明借还流程里有库存没有回补或扣减的记录按图索骥去对应的时间点排查事务。6.2 并发演示循环脚本看库存会不会穿帮答辩前务必做一次并发验证方法极简。先准备 10 个读者 ID然后用脚本同时请求借同一本书for i in $(seq 1 10); do curl -s -X POST http://localhost:8080/borrow?bookId1readerId$i done wait执行后查这本书的 available_stock。如果只剩一本的书被借出两次说明行锁或事务没生效赶紧回到 4.3 检查 selectForUpdate 有没有真正进入 mapper.xml。这个脚本我在自己项目里反复用比手工点十遍页面快得多。6.3 论文与源代码的对应文档章节跟着代码走写论文前先建一张对应关系表需求分析对应第 2 章的模块拆解表数据库设计对应第 3 章的建表 SQL 和字段说明概要设计对应 2.3 的工程结构图核心功能实现对应第 4 章的借还时序与事务说明测试章节对应上面的验证 SQL 和并发脚本。每写一节就回头给对应代码截图论文不会卡壳。我当年交这类课设时答辩现场借书后库存没回补查了一晚上才发现是 Transactional 自调用导致事务失效。这个教训让我此后每写一个管理系统的第一步就是先验证事务注解是否真的生效。希望这些经验能帮你少踩一次同样的坑把精力留在真正值得打磨的业务细节上。本文还有配套的精品资源点击获取
