图书馆管理系统完整源码：从数据库设计到借还书业务闭环的实战解析

简介：图书馆管理系统完整源代码面向Web开发初学者、计算机相关专业学生及有二次开发需求的开发者，是一套可运行、可扩展的B/S架构参考项目。资源共175个文件，压缩包仅482KB，其中包含26个C#源文件、23个ASP.NET页面、17个JavaScript脚本及90个GIF等图片资源，同时带有数据库文件与配置文件，基本覆盖用户管理、图书管理、借阅归还、预约查询、统计分析等核心模块。通过研读这套代码，可以快速理解分层架构、数据库表设计与ASP.NET WebForms开发流程，也能直接部署运行并对界面、权限、业务逻辑进行定制修改，适用于课程设计、毕业设计或企业内部管理系统搭建。目前已有5700余人浏览学习，代码结构清晰，含多个业务页面及辅助脚本，便于按需检索与学习。 每隔一段时间就有人找我要同一份东西：图书馆管理系统（完整源代码）。要的人里有正在做课程设计的大学生，有准备毕业设计的，也有刚开始学后端，想找一个完整项目拆着看源码的同学。今天这篇我就把整套系统的设计思路、核心代码片段、以及源代码里那些注释里根本看不出来的坑一次讲清楚。

先说结论：这个项目远没有很多初学者想的那么简单，只建三张表、写几个增删改查页面，那最多算“图书信息维护系统”，不叫“图书馆管理系统”。完整源码的关键在于业务闭环：图书能借、能还、能算逾期费、能查历史记录、能控制库存余量、还能防并发情况下的重复借还。把这些串起来，才是答辩老师眼里“有含金量”的完整源代码。

1. 为什么“图书馆管理系统”是最好的完整源码练手项目

1.1 功能边界刚好卡在“能看懂”和“有含金量”之间

我帮人调过不少课程设计项目，最大的问题不是代码不会写，而是项目规模选错了。选商城系统，涉及商品、购物车、订单、支付、库存、优惠券，一个人做完至少一个月；选学生信息管理系统，又太单薄，无非就是增删改查，答辩时问两句就没内容了。

图书馆管理系统正好卡在中间。它没有支付这种强外部依赖，但又有明确的业务约束：一本书的库存不能为负，同一本图书的副本数量要管理，借书后要在到期时间前归还，还书时要判断是否逾期并计算费用。这些规则不复杂，却足够让你把「事务、锁、状态机、唯一约束」这些后端基本功都过一遍。

对于初学者来说，它的数据关系也非常容易理解。图书和读者是多对多，中间借阅记录表是关键。你不需要花时间纠结业务概念，可以把全部精力放在代码结构和技术实现上。

1.2 技术栈选择：先扫清楚几种常见方案

我在决定用哪套技术栈写完整源码之前，先列了下面的选项：

如果让我推荐，我会选第四种里的后半部分思路，也就是 Spring Boot 做后端，页面用 Thymeleaf 或者 Bootstrap 写一套管理界面，但不要硬拆前后端分离。原因很实在：前后端分离会引入跨域、Token 鉴权、接口文档一堆额外知识，课程设计阶段容易把精力耗散到和业务无关的地方。

Spring Boot 的好处是约定大于配置，写出来的源码结构清晰，分 Controller、Service、Mapper 三层，谁都能看懂。MyBatis-Plus 则帮我们省掉了大量重复的单表 CRUD 代码，可以腾出精力写真正核心的借书还书逻辑。

2. 完整源代码的地基：表结构不能只建“书、人、记录”三张表

2.1 真正需要有的五类表

看一份源代码好不好，我第一件事就是打开数据库脚本。很多人交上来的“完整源代码”只有三张表：图书表、用户表、借阅表。这种设计不是不能用，但只能算勉强能跑。

一个能拿出来讲清楚的设计，至少要有这几张表：

• 图书信息表book_info：存书名、作者、出版社、ISBN、总库存、可借库存、上架状态
• 分类字典表category_dict：存图书分类，避免直接在图书表里写死分类字符串
• 读者/用户表sys_user：存账号、密码、姓名、角色，管理员和读者可以用同一张表
• 借阅记录表borrow_record：存谁在什么时候借了哪本书、应还时间、实际归还时间、逾期费用
• 操作日志表operation_log：记录谁在什么时间做了借书、还书、上架、下架等操作

图书表的建表脚本可以这样写：

CREATE TABLE book_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(32) NOT NULL, title VARCHAR(120) NOT NULL, author VARCHAR(80) NOT NULL DEFAULT '', publisher VARCHAR(120) DEFAULT '', category_id BIGINT, total_count INT NOT NULL DEFAULT 0, available_count INT NOT NULL DEFAULT 0, 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, UNIQUE KEY uk_isbn (isbn) );

注意这里把 ISBN 设置了唯一键，但没有让它当主键。因为 ISBN 虽然唯一，但实际借阅时不应该用这么长的号去关联记录，中间表用自增主键，性能和写 SQL 的体验都会好很多。

借阅记录表是这个系统的核心，设计时要把状态和费用字段都留好：

CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, reader_id BIGINT NOT NULL, book_id BIGINT NOT NULL, borrow_time DATETIME NOT NULL, due_time DATETIME NOT NULL, return_time DATETIME DEFAULT NULL, fine_amount DECIMAL(10, 2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0 COMMENT '0-借出中 1-正常归还 2-逾期归还', KEY idx_reader (reader_id), KEY idx_book (book_id) );

2.2 库存字段分开设计：total_count 和 available_count

这是最容易被忽略的一个点。很多人设计图书表时只有一个总数量字段，可借数量用什么？现场查borrow_record表里 status=0 的条数去算。

小数据量没问题，但一旦记录多起来，每次列表都要子查询统计，数据库压力会非常大。更重要的是，在借书的时候，你要先判断“这本书有没有余量”，如果每次都是查一遍再判断，多人同时借最后一本书时，就会出现超借。

正确做法是保存一个可借库存available_count。每次借书成功就减一，还书成功就加一。这个字段还可以用一条带条件的 UPDATE 语句来保证不会减成负数，这部分后面详细讲。

2.3 外键：要不要加物理外键

很多教材里推荐建表加FOREIGN KEY，但在真实项目中，尤其用 MyBatis-Plus 这类框架时，物理外键反而容易成为麻烦。原因有三点：

• 删除分类或图书时，外键约束会直接报错，导致很多初始化数据脚本跑不通
• 分布式或后期分库时，物理外键根本没法跨库生效
• 框架生成的实体反向工程时，外键关联容易产生额外查询

我的建议是：表结构上用索引维护关系，逻辑上的外键靠 Service 层确保。比如删除一个分类前，先查book_info里还有没有图书引用它；删除读者前，先查有没有未归还的借阅记录。这种代码写出来，答辩时反而比一句“数据库自动约束”更有说服力。

3. 三个最容易被答辩老师盯上的业务点

3.1 借书：用“条件更新”而不是“先查后改”

先看一段很典型的初版代码：

BookInfo book = bookInfoMapper.selectById(bookId); if (book.getAvailableCount() > 0) { book.setAvailableCount(book.getAvailableCount() - 1); bookInfoMapper.updateById(book); }

问题在哪？假如selectById查到可借数量是 1，两个用户同时进入这个判断，都认为还有书，然后都执行扣减，库存就变成 -1 了。数据库的默认隔离级别下，这种竞态是完全可能发生的。

所以核心的扣减逻辑不能用“先查后改”，要用一条 SQL 完成判断和更新：

UPDATE book_info SET available_count = available_count - 1 WHERE id = #{bookId} AND available_count > 0

如果返回值是 1，说明扣减成功；如果返回值是 0，说明这本书刚好没库存了。Service 层的代码是这样：

@Transactional(rollbackFor = Exception.class) public Long borrow(Long readerId, Long bookId) { int updated = bookInfoMapper.reduceAvailable(bookId); if (updated == 0) { throw new BusinessException("这本书刚好被借完，手慢了"); } BorrowRecord record = new BorrowRecord(); record.setReaderId(readerId); record.setBookId(bookId); record.setBorrowTime(new Date()); record.setDueTime(Date.from(LocalDateTime.now().plusDays(30) .atZone(ZoneId.systemDefault()).toInstant())); record.setStatus(0); borrowRecordMapper.insert(record); return record.getId(); }

@Transactional保证扣减库存和插入借阅记录要么都成功，要么都失败。如果插入借阅记录失败，库存会自动回滚，不会出现记录没有但库存少了的问题。

3.2 还书：状态流转和逾期费一起算

还书比借书更考验细节。还书时要做三件事：

1. 把借阅记录状态改成已归还
2. 给这本书的available_count加一
3. 如果超过应还时间，计算逾期费用

状态流转最好固定为：0 借出中->1 正常归还，或者0 借出中->2 逾期归还。不要用status一个字段表示太多含义，比如 0 未还、1 已还、2 续借中、3 挂失，这样的设计到后面自己都会绕晕。

计算逾期费时，我见过最离谱的写法是用时间戳差值除以一天的毫秒数，然后四舍五入。这种计算一旦跨天就会出现少算或多算。正确做法是先把时间转成本地日期，再按日粒度计算：

@Transactional(rollbackFor = Exception.class) public void giveBack(Long recordId) { BorrowRecord record = borrowRecordMapper.selectByIdForUpdate(recordId); if (record == null || record.getStatus() != 0) { throw new BusinessException("借阅记录不存在或已归还"); } LocalDate returnDate = LocalDate.now(); LocalDate dueDate = record.getDueTime().toInstant() .atZone(ZoneId.systemDefault()).toLocalDate(); int status = 1; BigDecimal fine = BigDecimal.ZERO; if (returnDate.isAfter(dueDate)) { long days = ChronoUnit.DAYS.between(dueDate, returnDate); fine = BigDecimal.valueOf(days).multiply(BigDecimal.valueOf(0.5)); status = 2; } record.setReturnTime(new Date()); record.setStatus(status); record.setFineAmount(fine); borrowRecordMapper.updateById(record); bookInfoMapper.increaseAvailable(record.getBookId()); }

selectByIdForUpdate是对这条借阅记录加行锁，防止用户开两个页面同时提交还书，导致状态被改两次、库存被重复加。对于课程设计级别的系统，这个锁的粒度已经足够了。

3.3 列表分页：为什么我不用 PageHelper

很多老项目喜欢用 PageHelper，它确实方便，一行代码就自动分页。但前提是你的 SQL 比较简单。一旦遇到多表联查、子查询、GROUP BY这种复杂 SQL，PageHelper 对 count 语句的改写很容易出错，查出来的 total 是 0，或者分页的 SQL 被拼错。

在新一点的源码里，直接用 MyBatis-Plus 自带的分页插件更省心：

IPage<BookInfo> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<BookInfo> wrapper = Wrappers.<BookInfo>lambdaQuery() .like(StringUtils.hasText(keyword), BookInfo::getTitle, keyword) .eq(categoryId != null, BookInfo::getCategoryId, categoryId); IPage<BookInfo> result = bookInfoMapper.selectPage(page, wrapper);

不管后续怎么扩展，我建议你自己封装一个统一的分页返回对象，包含total、records、pageNum、pageSize四个字段。前端拿到这份数据，才能做一个正常的表格分页组件。

4. 能发出去当“完整源代码”的项目，安全这关必须过

4.1 密码和数据库连接信息

我收到过不少同学发来的源码压缩包，打开application.yml，管理员密码明文写着 123456，数据库密码也直接写在里面。这种源代码就算功能再完整，交出去也是减分项。

密码存储必须用 BCrypt 这类不可逆加密，不要用 MD5，MD5 对弱密码的破解成本太低了。Spring Security 里的BCryptPasswordEncoder可以直接用。

数据库连接信息也不要写死，改成环境变量引用：

spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: ${DB_USER} password: ${DB_PASSWORD}

然后给一个.env.example或者application-example.yml，把真实的 IP、账号、密码去掉。别人拿到源码后，复制一份改成自己的配置就能启动，这才是“完整源代码”该有的交付质量。

4.2 SQL 注入和 XSS 别靠前端防

在 MyBatis 里，SQL 注入问题多数出在${}和#{}的使用区别上。我强烈建议所有用户输入的条件都走#{}。比如按书名搜索，千万不要写这样：

<select id="searchBook" resultType="BookInfo"> SELECT * FROM book_info WHERE title LIKE '%${keyword}%' </select>

而是应该写：

<select id="searchBook" resultType="BookInfo"> SELECT * FROM book_info WHERE title LIKE CONCAT('%', #{keyword}, '%') </select>

${}是字符串拼接，如果用户在搜索框里输入%' OR 1=1 --，那整个查询条件就会被改写。用#{}时 MyBatis 会把它编译成预编译参数，从根源上堵住这个洞。

XSS 也很常见，图书名称、公告内容这些字段提交上来之后，如果直接渲染到页面上，脚本就能执行。兜底做法是在后端增加一个 HTML 转义过滤器，至少要把<script>这样的标签处理掉。

4.3 操作日志

图书馆管理系统的“完整”程度，很多时候从日志表就能看出来。图书被谁修改过、借书还书操作是什么时候做的，这些信息在真实业务里非常重要。

我建议至少记录四个字段：操作人、操作类型、操作对象、操作时间。不要为了省事写到文件日志里，存数据库表的好处是管理端可以直接查，答辩现场想演示也方便。

5. 我在这套源码上踩过的几个坑

5.1 日期差计算不是简单的毫秒除以一天

第一次写还书功能时，我用的是这么一行代码：

long days = (returnTime.getTime() - dueTime.getTime()) / (24 * 60 * 60 * 1000);

看起来没错，但有几个边界陷阱：如果还书时间是晚上 23:59，到期时间是当天 00:00，时间戳差值会小于一天但跨了日期，计算结果就是 0。后续版本改成用LocalDate计算，只比较年月日，才彻底解决。

逾期费的计算口径一定要写清楚。我常用的规则是：还书当日不计入逾期天数，超过应还日第二天开始算，每天 0.5 元封顶 30 元。这个规则要写进 README，否则源码给别人后，别人不知道为什么逾期费是这个数。

5.2 重复提交和并发还书

借书按钮被双击，或者前端超时后用户又点了一次，都会导致同一本书被借两次。仅靠前端disabled按钮不够，后端必须做防护。

我在借阅记录表上加了一个条件约束的思路：判断同一读者是否已经借了同一本“未归还”的书，如果存在就不能再借。查询 SQL 类似这样：

SELECT COUNT(*) FROM borrow_record WHERE reader_id = #{readerId} AND book_id = #{bookId} AND status = 0

在最后还是保留了这个判断，同时配合事务行锁使用。还书侧的重复提交主要靠status判断，因为selectByIdForUpdate拿到记录后，先判断状态不是 0 就直接抛出异常，第二次请求进来时自然就拦截住了。

5.3 图书编号到底用 ID 还是 ISBN

很多移值需求里，管理员扫的是图书条形码，也就是 ISBN。如果代码里所有接口都按自增 ID 操作，扫描枪扫出来的 ISBN 就要先查一次再拿 ID，多一步倒无所谓，但容易漏掉 ISBN 重复的情况。

同一本图书的多个副本在系统里通常是一条记录，可用total_count表示副本数。所以数据初始化时，遇到 ISBN 相同的记录应该做数量累加，而不是直接插入新记录。我给导入功能写了一个规则：先按 ISBN 查库，存在就total_count + 1、available_count + 1，不存在才新增。这样无论用 ID 还是 ISBN 作为入口，数据都不会乱。

6. 从这份源码还能改造成什么

这套系统跑通之后，千万不要急着把它封存。它其实是一个非常难得的改造试验台。

如果你想练缓存，可以把热门图书的查询结果加一层 Redis。但要特别注意，available_count这个字段更新频率很高，不适合长时间缓存。我的建议是只缓存图书列表和分类列表，缓存时间控制在几分钟以内，借还操作时主动清掉相关缓存。

如果你想练消息队列，可以做一个“借书成功通知”功能。借书成功后向队列里发一条消息，由消费者负责发送邮件或站内信。不需要引入多复杂的中间件，RabbitMQ 就能演示完整链路。

如果你想提升简历的含金量，不要在项目描述里只写“实现了图书的增删改查”。你可以写：基于 Spring Boot 构建图书馆管理系统，通过乐观锁控制图书库存扣减，使用数据库事务保证借还数据一致性，设计了逾期费用计算和操作日志记录等业务闭环。这句话和“实现增删改查”放在一起，招聘方看到的完全不是同一个水平。

最后分享一个我自己的习惯：每次准备交付一套完整源代码之前，一定会把数据库删掉，从头执行一遍初始化脚本，再按 README 里的启动步骤重跑一遍。这一步能发现所有“我电脑上能跑”的隐藏问题。源码完整的意义不在于文件多，而在于换一台电脑、换一个人，按文档操作也能把系统跑起来。这个标准，值得每一个写课程设计的人记住。

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