企业官网建设流程全解析

简介：面向计算机专业毕业设计的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 模块拆解：五张表对应五组页面，先把边界画清楚

图书馆书库管理系统，业务上就四件事：管书、管人、管借还、管统计。往下拆，就得到下面这些模块和对应的数据表、页面。开发前一定要把模块边界画清楚，不然后面加需求时表结构会改到想哭。

为什么这样拆？核心在于“借阅”这个动作在数据模型上是典型的多对多：一个读者可以借多本书，一本书也能被多个读者先后借阅，所以必须拆出一张中间表 borrow_record 来记录每次借还。分类和图书是 1 对多，分类表要优先建，否则后面图书表加外键时又要回头补数据。另一个容易漏的细节是每本书的“馆藏总量”和“在库可借量”直接冗余在 book 表里，而不是每次查询时现算。列表页每页都要显示几十本书的在库量，如果每行都去 count 借阅记录，数据量稍大页面就会明显变慢，这是做管理信息系统最基础的冗余换性能思路。

模块清单定完后，不要急着写代码。先把每个页面要展示哪些字段列出来，比如图书列表需要“书名、作者、分类、在库量、书架位置”，新增图书表单需要“ISBN、书名、作者、出版社、出版日期、分类、馆藏总量、书架位置”。这一步做完，后面建表、写页面、写论文里的需求分析都有现成素材。

2.2 两条技术路线：JSP + Servlet 与 Spring Boot，怎么选不后悔

这个题目常见的实现路线有两条。一条是传统的 JSP + Servlet + JDBC ，另一条是 Spring Boot + MyBatis（或 JPA）。两条路线各有明确的适用场景，别听别人说“老技术过时了”就一票否决，也别觉得“框架越新越好”硬上微服务。

我的常见做法是：课设选 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 只做参数接收和页面跳转，业务判断全部放到 service，SQL 写在 mapper.xml。答辩时老师问“借书超期怎么判断”，你要能一层层指给他看：页面请求进 BorrowController，判断逻辑在 BorrowService 的 returnBook 方法，SQL 在 BorrowRecordMapper.xml。如果全写在 controller 里，代码短的时候看不出问题，借还逻辑一复杂就变成大泥球。

pom.xml 里最关键的依赖就这几个：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

Spring 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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/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: true

url 里的参数每一个都有用：useUnicode 和 characterEncoding 保证中文不乱码；serverTimezone=Asia/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_time，name 要加唯一约束，避免“文学”和“文学 ”这种重复分类混进去。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 '创建时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='管理员表';

逐条说明关键参数。字符集用 utf8mb4 而不是 utf8，因为 MySQL 的 utf8 最多存 3 字节，遇到 emoji 或生僻字会直接报错，utf8mb4 是完整 UTF-8。引擎指定 InnoDB 是因为它还债必需：事务和外键。MyISAM 不支持事务，借书时要同时完成“插入借阅记录”和“扣减库存”，如果不是在一个事务里执行，中间任何一步失败都会让数据对不上账。金额字段用 DECIMAL(10,2) 而不是 FLOAT 或 DOUBLE，二进制浮点数算钱会有 0.1+0.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 改为 1，return_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 UPDATE：

SELECT * 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 连接串带上 characterEncoding=utf8；建表用 utf8mb4（见第 3 章）；JSP 页面顶部加 <%@ page contentType="text/html;charset=UTF-8" %>，Controller 返回 JSON 时在 @RequestMapping 上指定 produces = "application/json;charset=UTF-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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

allowPublicKeyRetrieval=true 是 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?bookId=1&readerId=$i" & done wait

执行后查这本书的 available_stock。如果只剩一本的书被借出两次，说明行锁或事务没生效，赶紧回到 4.3 检查 selectForUpdate 有没有真正进入 mapper.xml。这个脚本我在自己项目里反复用，比手工点十遍页面快得多。

6.3 论文与源代码的对应：文档章节跟着代码走

写论文前，先建一张对应关系表：需求分析对应第 2 章的模块拆解表，数据库设计对应第 3 章的建表 SQL 和字段说明，概要设计对应 2.3 的工程结构图，核心功能实现对应第 4 章的借还时序与事务说明，测试章节对应上面的验证 SQL 和并发脚本。每写一节就回头给对应代码截图，论文不会卡壳。我当年交这类课设时，答辩现场借书后库存没回补，查了一晚上才发现是 @Transactional 自调用导致事务失效。这个教训让我此后每写一个管理系统的第一步就是先验证事务注解是否真的生效。希望这些经验能帮你少踩一次同样的坑，把精力留在真正值得打磨的业务细节上。

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