简介：这是一套基于Spring Boot和MySQL的图书馆管理系统项目资源，面向需要完成毕业设计或课程设计的学生，同样适合想快速搭建后台管理Web应用的开发者。内含项目全套源码与完整文档，源码经过测试校正可稳定运行。压缩包共385个文件、约6.24MB，主要包含Java后端代码与编译后的class文件、前端页面及样式脚本、数据库建表脚本、Maven相关配置与依赖，以及丰富的图片和动图展示素材；目录按前台、后台、安全设计等模块划分，并附带可执行启动脚本，便于对照学习和二次开发。系统在前台实现登录界面、读者编辑个人信息、馆藏书籍查询、个人借阅记录管理，后台则提供用户管理、书籍管理、借阅记录管理，并覆盖安全设计；配套文档对各模块进行说明，有助于理解控制层、业务层、数据访问层的分工，可快速部署演示，也可作为毕业设计答辩的参考资料。已有1590人学习下载，可以用作管理系统类项目的实践资料。

1. 基于Springboot+mysql的图书馆管理系统：这东西到底解决什么问题？

一家高校分馆或者街道图书馆，靠 Excel 记录借还书。每天开馆第一件事就是对账，看谁超期、谁续借时写错了条码，馆长一边翻台账一边叹气——这大概是很多小馆的常态。而这个标题里的方案，基于 Spring Boot + MySQL 的图书馆管理系统，就是把这个常态打破的标准姿势：一个能跑起来的管理端，一套完整的图书信息表和借阅流水，再加上一份能照着部署的文档，落地周期按天算。

这套系统适合三类人：正在做毕业设计想少走弯路的学生，需要给中小型场馆做信息化改造的开发者，以及想用一个完整 CRUD 项目作为作品集的初级研发。它的技术范围不算大，也正因为不大，正好把“借书、还书、续借、超期罚款”这类高频小事务如何做到不丢数据、能对上账这件事讲透彻了。接下来我按最常规的工程形态来讲实现路径，包括数据模型、关键接口、事务边界和排错，你可以照着改。

2. 一上手就要定的事：技术栈理由、数据模型与六张核心表

2.1 为什么是 Spring Boot + MySQL，而不是别的组合

很多人的第一反应是：图书馆管理系统没什么技术含量。确实，从纯 CRUD 的角度看它不复杂，但真正接需求时，有几个点决定了技术选型。

第一个是事务边界。借书动作要同时写图书表（库存减一）、写借阅记录、改读者表（借阅数加一），三个操作必须一起成功或一起失败。MySQL 的 InnoDB 引擎配合 Spring 的@Transactional注解，在单库场景下能把这件事做得很稳。如果换成 NoSQL 或者没有事务能力的框架，你需要自己写补偿逻辑，成本立刻上去了。

第二个是生态和文档。图书馆管理系统大概率要运行在不那么新的服务器上，MySQL 5.7 和 8.0 都是被反复验证过的版本，Spring Boot 的 Starter JDBC、MyBatis 或 JPA 都有大量生产案例。说得直白一点：出了问题你能在网上找到答案，这本身就是中小型项目最需要的特性。

第三个是交付形态。标题里带了“源码+文档”，说明它面向学习或二次开发，资料齐全比极端性能更重要。Spring Boot + MySQL 的工程结构约定俗成，新接手的人看项目不需要花太多时间，这对毕设或团队传承都是加分项。

2.2 六张核心表怎么拆：把业务对象映射成关系

我一般会先把业务对象捋一遍：图书、读者、借阅流水、图书分类、管理员用户、罚款单。常见做法是做成六张表，其中书和分类是多对一，读者和借阅流水是一对多，借阅流水和图书是借出时的快照关系。

这里有个容易被想错的地方：借阅记录要不要冗余图书信息？我建议冗余。因为图书价格、出版社这些信息可能变动，而借阅记录需要保留“当时借的是什么版本”的事实。同理，借阅流水里要带due_time（应还时间），而不是等归还时现算。

下面是建表 SQL 的骨架，完全兼容 MySQL 8.0，也能在 5.7 上跑：

CREATE TABLE `book` ( `id` bigint NOT NULL AUTO_INCREMENT, `isbn` varchar(32) NOT NULL COMMENT 'ISBN编号', `title` varchar(128) NOT NULL COMMENT '书名', `author` varchar(64) DEFAULT NULL COMMENT '作者', `category_id` bigint DEFAULT NULL COMMENT '分类ID', `stock` int NOT NULL DEFAULT '0' COMMENT '可借库存', `total_stock` int NOT NULL DEFAULT '0' COMMENT '馆藏总量', `status` tinyint NOT NULL DEFAULT '1' COMMENT '1上架 0下架', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_title` (`title`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

建表时先把时间字段的默认值写好，后面代码里就少写很多setCreateTime(new Date())这种无意义的行。title加了索引，因为图书检索的常态是按书名模糊搜索；如果未来要做全文检索或者拼音首字母匹配，那是后话，索引要从查询频率倒推出来。

借阅记录表borrow_record需要记录四个关键时间：借出时间borrow_time、应还时间due_time、实际归还时间return_time，以及超期产生的罚款字段fine_amount。这里最核心的设计点：due_time不能靠查询时动态算，必须在借出那一刻落库，否则后续修改借期规则时，老记录怎么算都说不清。

CREATE TABLE `borrow_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL, `book_id` bigint NOT NULL, `book_title` varchar(128) NOT NULL COMMENT '借出时的快照', `borrow_time` datetime NOT NULL, `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) DEFAULT '0.00' COMMENT '罚款金额', PRIMARY KEY (`id`), KEY `idx_user_status` (`user_id`, `status`), KEY `idx_due_time` (`due_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

注意idx_user_status是联合索引，查“某读者当前借了什么书”是最常见的查询，联合索引可以避免回表。表里冗余book_title之后，查流水列表时不需要每次 JOIN 图书表，对性能友好，对代码也友好。

2.3 字段类型、字符集与排序规则：三个一开始就要注意的参数

很多工程做了一半才回来改字符集，那时候数据已经进去了，改起来非常痛苦。我建议建库直接用utf8mb4而不是utf8，因为utf8mb4才能真正存下 emoji 字符，MySQL 8.0 的默认字符集也是它。如果你的系统里有读者留言、书名备注里含有生僻字或 emoji，utf8会直接报错Incorrect string value，这种问题在线上出现一次，就够你记一辈子。

排序规则collate我一般选utf8mb4_unicode_ci，它比较符合中文场景对排序和大小写不敏感的预期。另一个容易踩的点是金额字段，罚款金额用decimal(10,2)，别用float。float在做财务加法时会慢慢出现精度偏移，虽然单条记录看不出问题，一旦累计就和手工台账对不上。

库表命名也值得提前统一：表名全小写加下划线，字段名带上业务前缀，比如borrow_time而不是time。MySQL 在 Linux 下区分表名大小写，Windows 不区分，如果你在 Windows 开发、Linux 部署，大小写不一致的表名是经典的部署翻车现场，这个坑几乎每个项目都会有人踩一遍。

3. 把借还书流程跑通：Controller、Service、Mapper 三层的核心代码

3.1 为什么用三层结构，每层只干一件事

图书馆管理系统的规模没有必要上 DDD 或 CQRS，经典三层 Controller-Service-Mapper 是最稳的方案。Controller 只做参数接收和响应包装，Service 处理业务规则，Mapper 只跟 SQL 打交道。这样做的好处是：当你要加“管理员审核读者”这种规则时，只改 Service，不动接口和数据访问层。

我见过太多毕设项目把 SQL 直接写在 Controller 里，当时很快，后续要加权限、加日志时全乱了。这个项目规模不大，但分层带来的维护收益依然成立——尤其是接手人不是你自己的时候。

3.2 图书检索接口：分页、模糊查询、状态过滤

图书检索是最常被问“怎么优化”的接口。核心 SQL 是title LIKE ? AND status = ?加上 MySQL 的LIMIT分页。这里给出一个直接能用的 Mapper 实现，用的是 MyBatis-Plus 风格：

// BookMapper.java @Select("<script>" + "SELECT id, isbn, title, author, stock, total_stock, status " + "FROM book " + "WHERE status = 1 " + "<if test='keyword != null and keyword != \"\"'>" + " AND (title LIKE CONCAT('%', #{keyword}, '%') OR isbn LIKE CONCAT('%', #{keyword}, '%'))" + "</if>" + "ORDER BY id DESC " + "LIMIT #{offset}, #{pageSize}" + "</script>") List<Book> searchBooks(@Param("keyword") String keyword, @Param("offset") Integer offset, @Param("pageSize") Integer pageSize);

重点说两个参数。offset = (pageNo - 1) * pageSize，这个换算放在 Service 层而不是 SQL 里；pageSize一定要在入口做上限控制，公共接口如果不限 size，一次拉出几万条记录，数据库和前端都扛不住。常见做法是最大 50 条，超出直接拒绝。

上面这段是动态脚本，MyBatis-Plus 也有QueryWrapper写法，效果一样。如果你用原生 JDBC 或 JPA，逻辑也是同一套。这个接口真正的坑点在于：LIKE '%keyword%'这种前模糊匹配即使title建了索引也用不上，数据量到几十万级别之后检索会明显变慢，到时候可以再加全文索引或改成前缀匹配。

3.3 借书接口：扣库存、写流水、更新读者借阅数必须在同一事务里

借书是最能体现“为什么要有事务”的业务。一次借书请求背后有三件事：检查库存是否充足；book表stock减一；borrow_record插入一条新记录。如果中途某个写操作失败，库存已经扣了但流水没记上，这本书就凭空消失了。解决这个问题的标准姿势是@Transactional注解加在 Service 方法上。

下面这段借书逻辑可以直接套用：

// BorrowService.java @Transactional(rollbackFor = Exception.class) public Long borrow(Long userId, Long bookId, Integer borrowDays) { // 1. 查书，带行锁 Book book = bookMapper.selectByIdForUpdate(bookId); if (book == null || book.getStock() <= 0) { throw new BizException("图书库存不足或已下架"); } // 2. 扣库存（用 SET stock = stock - 1 而不是先查后改） int updated = bookMapper.deductStock(bookId); if (updated != 1) { throw new BizException("并发借阅，库存扣减失败"); } // 3. 写借阅流水 BorrowRecord record = new BorrowRecord(); record.setUserId(userId); record.setBookId(bookId); record.setBookTitle(book.getTitle()); record.setBorrowTime(new Date()); record.setDueTime(DateUtils.addDays(new Date(), borrowDays)); record.setStatus(0); borrowRecordMapper.insert(record); return record.getId(); }

重点在三个细节。第一处是selectByIdForUpdate，MySQL InnoDB 对同一行数据的 UPDATE 会排他，但当两个并发请求同时SELECT到stock=1，然后都通过判断、都执行扣减，最终库存会变成-1。用SELECT ... FOR UPDATE加锁读，或者直接靠UPDATE的受影响行数来判断，都是对的解法。

第二处是扣库存的 SQL 写成UPDATE book SET stock = stock - 1 WHERE id = ? AND stock > 0。如果返回影响行数为 0，说明并发下库存已经没了，直接抛异常，这样最稳。这里不要写UPDATE book SET stock = #{stock} - 1，因为那需要先把 stock 查出来再放回去，多一步就多一个并发窗口。

第三处注意rollbackFor = Exception.class。Spring 的@Transactional默认只在RuntimeException时回滚，如果你的BizException是受检异常（继承Exception），不加rollbackFor会导致事务不提交也不回滚，数据卡在中间状态。这个是教科书里反复讲、现场反复犯的坑，后面排错章节会单列一条。

3.4 还书接口：更新状态、计算超期罚款、释放库存

还书和借书正好相反：更新borrow_record的return_time和status，判断是否超期并计算罚款，最后把book的stock加一。流程的难点不在 SQL，而在“超期金额怎么算才公平”。

超期罚款 = 超期天数 × 每日罚款单价。罚款单价建议做成系统参数，不要写死在代码里，因为不同图书馆对不同类型的书有不同的规则——小说类可能每天 0.5 元，工具书每天 2 元。另一个边界是：还书当天如果恰好是到期日不算超期，判断用dueTime.before(now)而不是dueTime.before(now) || dueTime.equals(now)，日期比较用LocalDate或毫秒值，不能直接用字符串比。

还书逻辑里还有一个容易被漏掉的地方：已超期未还书的读者能不能再借新书？这个属于业务规则，建议放在借书 Service 的开头检查，而不是放在还书里。借书方法开头加一条查询即可：SELECT COUNT(*) FROM borrow_record WHERE user_id = ? AND status = 0 AND due_time < NOW()，有记录就直接拒绝新借书。

4. 数据库连接、连接池与时区：Spring Boot 集成 MySQL 的配置细节

4.1 application.yml 里的关键参数，只列真正影响运行的

Spring Boot 集成 MySQL 的套路固定，但每次新项目我都要重新查一遍参数。下面是一个实际能用的 yml 配置：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/library?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: your_password hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000

driver-class-name值得单独说明。如果你用 MySQL 8.x 的驱动，类名是com.mysql.cj.jdbc.Driver；如果是老驱动mysql-connector-java5.x，要写com.mysql.jdbc.Driver。版本不匹配的典型现象是启动报Loading class com.mysql.jdbc.Driver is deprecated，项目还能跑，但这个警告不解决，早晚变成坑。

URL 里的参数大多是标配，有两个容易被忽略。第一个是serverTimezone，MySQL 8.0 里如果不指定时区，驱动会用 JVM 的默认时区；如果服务器是 UTC 而业务在东八区，存进数据库的时间会差 8 小时，超期判断会乱套。第二个是allowPublicKeyRetrieval=true，它只在 MySQL 8.0 的caching_sha2_password认证插件下需要，报错Public Key Retrieval is not allowed时加上就能解决。

4.2 连接池的四个参数为什么这么设

HikariCP 是 Spring Boot 2.x 之后的默认连接池，很多人全部用默认值，中小型并发场景下确实不用怎么调。但如果你把maximum-pool-size设得过大，反而可能坏事：MySQL 默认的max_connections是 151，如果 20 个应用实例每个开 50 条连接，直接把数据库打满，新连接全被拒绝，表现为应用偶发性报Too many connections。

我一般遵循的原则是：minimum-idle和maximum-pool-size不要相差太大，避免连接频繁创建销毁；idle-timeout要小于数据库的wait_timeout。MySQL 服务端默认wait_timeout是 28800 秒（8 小时），如果连接池里的空闲连接被服务端回收，而应用不知道，下一次请求就会报Communications link failure。HikariCP 的max-lifetime默认 30 分钟，比服务端的 8 小时小，通常没问题；但如果你改过数据库的wait_timeout，连接池参数就要跟着改。

4.3 时区问题的三种表现和定位方法

时区问题在图书馆管理系统里比想象中更常见，因为借阅场景对时间敏感。三种典型表现：数据库时间比本地晚 8 小时；某段时间查不到数据；超期罚款金额对不上。定位时先弄清楚三个时区：MySQL 服务端的time_zone、连接 URL 里的serverTimezone、Java 应用里 JVM 默认时区。

命令行执行SELECT @@global.time_zone, @@session.time_zone;能直接看到数据库时区。如果数据库是SYSTEM，最终取的是操作系统时区，这时候即使连接串写了serverTimezone=Asia/Shanghai也可能不一致。我建议固定做两件事：MySQL 的配置文件my.cnf里写default-time-zone = '+08:00'，连接 URL 里写serverTimezone=Asia/Shanghai，两处对齐。

4.4 慢查询和索引：图书馆系统的查询瓶颈在哪

图书检索、借阅记录查询、超期提醒，这三个接口最容易被数据量放大。借阅记录会随时间无限增长——长期使用的情况下，它是这个项目里唯一必然超过百万行的表。所以从一开始就要把索引设计到位，并留好查询条件的组合。

定期用EXPLAIN观察关键的 SELECT，重点关注type列是ALL（全表扫描）还是ref/range。常见问题：状态过滤字段和排序字段组合不当，导致 MySQL 排序时使用filesort；两个单列索引不如一个联合索引效果好。我之前处理过一个案例，查询某读者全部历史借阅记录，只建了user_id单列索引，没建(user_id, borrow_time)联合索引，导致每次查流水都全表扫，数据到二十万行后接口直接超时——加联合索引的 ALTER 语句执行完，问题从秒级降到毫秒级。

5. 图书馆管理系统的常见翻车地点：从环境安装到上线排错

5.1 MySQL 驱动版本不匹配导致项目起不来

现象：Spring Boot 项目启动时抛ClassNotFoundException: com.mysql.jdbc.Driver，或者提示 driver-class-name 配置了但找不到类。

原因：pom 里引入的mysql-connector-java版本和 yml 里写的类名不一致。5.x 驱动类名是com.mysql.jdbc.Driver，8.x 必须是com.mysql.cj.jdbc.Driver。另外，Spring Boot 2.x 的 BOM 会自动管理这个依赖的版本，如果你没有显式声明，它可能引入 8.x。

解决：先跑mvn dependency:tree查实际生效的连接器版本，再按版本写类名。不要凭记忆选类名，这两个驱动类名的差异是这类问题最容易的解法。

5.2 MySQL 8.0 认证插件导致的连接失败

现象：应用启动后第一次访问数据库报Public Key Retrieval is not allowed。

原因：MySQL 8.0 默认使用caching_sha2_password认证，非 SSL 连接下首次握手需要获取公钥，JDBC 驱动默认不自动获取。

解决：在 JDBC URL 上追加allowPublicKeyRetrieval=true&useSSL=false。注意这个参数只解决握手问题；如果数据库要求 SSL，还需要配置证书，不过绝大多数局域网开发环境不需要。把这条加到 URL 后重启即可，不需要改数据库端。

5.3 事务没回滚：受检异常导致的库存错乱

现象：借书接口在插入流水时报了业务异常（比如读者已被禁用），但日志显示库存已经扣了，排查时数据不一致。

原因：@Transactional默认只回滚RuntimeException，自定义的BizException如果继承的是Exception，Spring 不会自动回滚。

解决：事务方法上加rollbackFor = Exception.class，或者让所有自定义异常继承RuntimeException。团队内部要约定统一：业务异常统一继承RuntimeException，这样之后每个方法不用再关注rollbackFor。我早期做这类系统时，一本借不出去的书库存变成 -1，就是这个原因。

5.4 物理删除图书导致历史记录消失

现象：删除一本下架图书后，借阅历史里查到的是空书名或者 JOIN 失败。

原因：borrow_record只存了book_id，没存冗余快照，图书删除后关联断裂。这类问题在文档未强调“物理删除还是逻辑删除”时特别容易发生。

解决：book表加status字段做逻辑删除，管理员关闭这本书的借出状态而不是DELETE记录。同时借阅流水表写库时把book_title等关键信息冗余进去，让历史查询不依赖 JOIN。这个设计在第 2 章建表时已经埋了伏笔，实际项目中强烈建议执行。

5.5 Docker 装 MySQL 失败：目录权限与初始化顺序

现象：docker run启动 MySQL 容器后马上退出，docker logs里看到Can't open file (errno: 24)或者权限相关错误。

原因：大多数是容器内数据目录权限问题，或者对宿主机挂载目录没有做正确处理。常见的是容器启动时，宿主机挂载目录的所有权不是容器内 mysql 用户（uid 999 或 1000）的。

解决：挂载本地目录时，先让容器自动初始化目录结构，不要提前在宿主机创建一堆文件。用一个干净目录启动一次，让它生成数据文件；如果日志提到chown或permission denied，对挂载目录执行chown -R 1000:1000，或者改用 Docker 具名卷-v mysql-data:/var/lib/mysql。不要直接chmod 777，后期会引入不少安全风险。

补充一个开发环境建议：Docker 跑 MySQL 做本地开发很舒服，但如果你打算部署到生产，要先把数据备份方案想清楚。容器重建时数据会保留在卷里，但如果没有做恢复演练，等真正丢数据那天再补课就迟了。

6. 进阶：把日志、权限和备份补上，系统才算真正能上线

到这一步，一个能跑通的图书馆管理系统已经具备了。但能用和能上线之间还有一段路。我建议在交付前做三件成本最低、收益最高的事。

第一，把管理员和读者的权限真正分开。很多人会把所有接口都放开，功能少的时候确实图省事，但要上线就绕不开：读者只能查书、借书、查自己的流水；管理员才具备上架、下架、罚款豁免、查所有人流水的能力。最轻量的做法是加一个拦截器校验角色码，不用引入 Spring Security 全家桶——一个没有外部登录集成的内网系统，用拦截器就够了。

第二，把借阅超期提醒做成定时任务。用@Scheduled(cron = "0 8 * * *")每天早上扫一遍due_time在未来三天内且status = 0的借阅记录，生成待提醒列表。这个功能不复杂，但它是这个系统最容易让使用方感知价值的点——“系统提醒我该还书了”，比任何后台功能都直观。

第三，把数据库备份脚本准备好。图书馆管理系统的数据量不可能大到要分库分表，但备份可能因为“觉得简单”而一直没做。我会写一个最简单的 cron 脚本，每天凌晨用mysqldump导出一份 SQL 文件，保留最近 7 天。它不是高级技巧，但能在出问题时救回一条命。

最后分享一个小教训：我早期接这类项目时，总想着把功能堆得多、页面做得炫，但真正上线后，馆长最在意的反而是“借出去的书记得回来，超期的书要能提醒”。从那以后，我每次做这种管理系统，第一个验证的就是“借书-还书-超期-补交罚款”这条闭环跑得稳不稳。参数可以调，页面可以改，但数据一致性和备份这两条红线一定不能省。希望这篇笔记能帮你少踩几个我踩过的坑。

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