简介：这是一份完整的图书管理系统毕业设计资料包，内含可运行的源代码与配套毕业论文，面向计算机相关专业学生，尤其适合需要完成课程设计或毕业设计、希望理解软件工程与数据库管理实际应用的读者。系统源代码覆盖用户注册登录与权限管理（区分管理员/普通用户）、图书录入与分类维护、借阅续借归还及历史记录、多条件快速检索、到期自动提醒、借阅频率统计分析等核心功能，代码结构清晰，便于二次开发；配套论文从需求分析、系统架构设计、技术选型、数据库ER模型与表关系设计，到功能实现逻辑、性能优化策略和测试方案均有详细论述，能帮助读者完整梳理从需求到落地的开发思路。压缩包为zip格式，整体约3.75MB，内容精简便于直接获取；截至目前已有213人学习参考，是图书管理类项目较为实用的参考样板。
1. 图书管理系统毕业设计(源代码+论文).zip：先搞懂你拿到的是什么再动手
一个叫图书管理系统毕业设计(源代码+论文).zip的压缩包，通常出现在两种场景：要么是你在答辩前从学长或资源站拖下来的“完整版”，要么是你准备拿它当模板改造成自己的课题。无论哪种，这个 zip 里装的都不是一个能直接双击运行的软件，而是一整套需要你重新“组装”的源码工程、数据库脚本和论文文稿。它解决的核心问题是：用一套现成的图书借阅管理业务，把增删改查、登录鉴权、借还书流程和论文说明一次配齐，省去从零构思课题的时间。它适合正在赶毕设、需要快速跑通 demo 并对论文数据格式有要求的学生，也适合想参考一个典型 Java Web 工程怎么组织代码的开发者。但注意，“完整版”不等于“解压就能跑”，真正让你花时间的，是环境匹配和数据库导入这两步。
2. 选型先于写码：图书管理系统 zip 为什么普遍走 SSM + MySQL
拿到一个毕设 zip，第一步不是解压，而是先判断它是什么技术栈。图书管理系统作为最经典的毕设题目，市面上流通的压缩包九成以上是 Java Web 方向，再细分就是 SSH（Struts2 + Spring + Hibernate）、SSM（Spring + SpringMVC + MyBatis）和 Spring Boot 三种。近几年流传的“源码+论文”版本，绝大多数是 SSM 或 Spring Boot。这里有个判断技巧：解压后看 pom.xml。有 pom.xml 且依赖里出现 spring-boot-starter-web 的是 Spring Boot；依赖里同时出现 spring-context、spring-webmvc、mybatis 的是 SSM；如果还有大量 struts2 相关 jar，那就是老 SSH，我建议你直接关掉换个包，SSH 在现在的主流 JDK 和 Tomcat 版本上兼容性很差，光是 Struts2 的漏洞修复补丁就能折腾你两天。
为什么 SSM 能占据毕设 zip 的半壁江山？因为它是一个“刚好多一点”的配置量。Spring Boot 虽然启动快、配置少，但很多学校的答辩老师对 Spring Boot 的“自动配置”不太买账，觉得没法考察你对框架原理的理解；而 SSM 的手工配置 xml 或注解，正好展示了 Bean 管理、AOP 事务、SQL 映射这三板斧。再加上 MySQL 5.7 + Tomcat 8.5 的经典组合，这整套方案在国内高校机房和导师机器上的复现成功率极高。我见过不少同学拿 Spring Boot 版去做答辩，结果导师现场问“拦截器在哪配置”“事务怎么失效的”，直接哑火；换回 SSM 反而能按着配置文件从头讲到尾。所以如果你拿到的是 Spring Boot 版，别急着高兴，先确认一下论文里的技术架构图和实际代码是否一致，很多 zip 里的论文是拿 SSM 版改的，技术栈对不上是重灾区。
选型还要考虑一个现实问题：你的机器上已有的环境是什么。比如你电脑里装的是 MySQL 8.0，而 zip 里的 sql 脚本是 5.7 导出的，那字符集排序规则和驱动版本就要处理。类似的，如果你本地只有 JDK 11，而工程编译级别是 1.8，用 IDEA 打开后需要在 Project Structure 里手动切。这类版本错配是毕设 zip 跑不起来的最大元凶，优先级远高于代码本身的 bug。我一般的处理顺序是：先确认 JDK 和 Tomcat 版本，再确认 MySQL 版本，最后才看代码。版本这关过了，后面基本是流程问题。
另外一个常见的选型疑问是：图书管理系统 python和php图书管理系统不是更轻量吗？轻量是真轻量，但“源码+论文”这种交付物生态里，Python 和 PHP 版本的工程规范度参差不齐。Flask 版通常只有视图层和裸 SQL，论文里想画一个三层架构图都凑不齐；PHP 版更是很多直接从老项目抠出来的，没有 composer 依赖管理，代码里还混着 HTML。从“能讲清楚 + 能写进论文”这个角度看，SSM 依然是中文毕设资料里沉淀最完整、网上踩坑记录最多的方向。你拿到的这个 zip 如果恰好是 SSM 版的，恭喜你，至少你在搜索引擎里能查到的每一个报错，都有人替你踩过。
提示：判断技术栈最快的路径是看压缩包内的文件后缀和典型目录。有
pom.xml是 Maven 工程；有webapp/WEB-INF/web.xml是传统 Servlet 工程；有application.yml或bootstrap.yml是 Spring Boot。不要把src目录直接拖出来运行，它只是 Java 源码的根路径。
3. 把“源码+论文”拆成可运行的工程：核心模块与数据库落地
3.1 zip 内的典型目录结构和交付物清单
一个制作规范的图书管理系统毕业设计 zip，内部一般是两个顶层目录：源代码（或叫source/project）和论文（或叫doc/thesis）。源代码目录如果是 IDEA 工程，结构长这样：
LibrarySystem/ pom.xml src/main/java/ com/example/library controller/ service/ dao/ entity/ interceptor/ util/ src/main/resources/ jdbc.properties mybatis-config.xml spring-config.xml springmvc-config.xml mapper/ BookMapper.xml UserMapper.xml BorrowRecordMapper.xml src/main/webapp/ WEB-INF/ web.xml index.jsp static/ admin/ sql/ library.sql README.md拿到手先别急着改，按这个清单核对一下是否齐全。缺sql目录的 zip 基本是残废——没有数据库脚本，代码里所有表名只能靠猜。缺mapper目录意味着 MyBatis 映射文件可能在 Java 包路径里和接口混放，这种情况还能跑，但你要在mybatis-config.xml里确认一下 mapper 扫描路径。最怕的是缺pom.xml，说明这是一个从 Eclipse 或 MyEclipse 里直接拷出来的工程，依赖全是 jar 包堆在WEB-INF/lib下，这种工程我在后面会专门说怎么救。
论文目录一般是一份 Word 文档加一份开题报告或任务书，这里的“完整版”指的不是论文文学的完整性，而是内容结构完整——摘要、目录、需求分析、概要设计、详细设计、测试、总结，各章节都有标题而不是只有占位符。你如果用这份论文去答辩，务必要把论文里的系统截图替换成你自己跑出来的界面截图，这是很多答辩翻车的直接原因：老师一眼看出截图里的系统时间、电脑主题和界面上显示的借阅记录对不上。
3.2 用户表、图书表、借阅记录表：一张建表 SQL 把业务串起来
图书管理系统的核心就三张表：用户表（含管理员和读者）、图书表、借阅记录表。建表脚本是你在论文“数据库设计”章节里要重点讲的部分，也是跑通系统的第一步。下面这份建表 SQL 是这类项目最常见的结构，字段命名采用下划线风格，和 MyBatis 的 mapUnderscoreToCamelCase 配置正好匹配：
-- 创建并选择数据库 CREATE DATABASE IF NOT EXISTS library_db DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci; USE library_db; -- 用户表：包含管理员（role=1）和读者（role=0）两种角色 CREATE TABLE `user` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL COMMENT '登录名', `password` VARCHAR(255) NOT NULL COMMENT '密码，MD5或BCrypt加密存储', `real_name` VARCHAR(50) DEFAULT NULL COMMENT '真实姓名', `role` TINYINT(4) NOT NULL DEFAULT '0' COMMENT '0=读者，1=管理员', `status` TINYINT(4) NOT NULL DEFAULT '1' COMMENT '1=正常，0=禁用', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4; -- 图书表：库存数量和可借数量分开维护，避免每次借阅都count CREATE TABLE `book` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `isbn` VARCHAR(20) DEFAULT NULL COMMENT 'ISBN编号，不是主键因为可能为空', `book_name` VARCHAR(100) NOT NULL, `author` VARCHAR(50) DEFAULT NULL, `publisher` VARCHAR(100) DEFAULT NULL, `category_id` INT(11) DEFAULT NULL COMMENT '分类ID，关联category表', `total_count` INT(11) NOT NULL DEFAULT '0' COMMENT '馆藏总量', `available_count` INT(11) NOT NULL DEFAULT '0' COMMENT '当前可借数量', `location` VARCHAR(100) DEFAULT NULL COMMENT '馆藏位置，如A区-3排', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4; -- 借阅记录表：一次借一条记录，还书时update归还时间 CREATE TABLE `borrow_record` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `user_id` INT(11) NOT NULL, `book_id` INT(11) NOT NULL, `borrow_time` DATETIME NOT NULL COMMENT '借出时间', `due_time` DATETIME NOT NULL COMMENT '应还时间，一般借出时间+30天', `return_time` DATETIME DEFAULT NULL COMMENT '实际归还时间，NULL表示未还', `status` TINYINT(4) NOT NULL DEFAULT '0' COMMENT '0=借出中，1=已归还，2=逾期未还', `renew_count` TINYINT(4) NOT NULL DEFAULT '0' COMMENT '续借次数，限制最多2次', PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_book_id` (`book_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;这里有几个值得留意的设计点。user表用了real_name而不是name，因为name在 MySQL 某些版本里是保留字，容易埋雷。password字段设为 255 而不是 32，是为了兼容 MD5 和 BCrypt 两种加密产物长度——如果代码里密码校验一直提示失败，先看看加密算法是 MD5 还是 BCrypt，很多 zip 里代码用的是 MD5，而你导入的 sql 里预置的密码却是 BCrypt 格式的密文，这种不匹配会让你以为系统坏了。available_count这个字段单独维护，而不是每次通过 count 计算在借数量，是为了列表查询的速度，代价是借书、还书、续借时都要在事务里同步 update 这张表，这也是你论文里“事务一致性”可以展开讲的素材。
《图书管理系统》这类题目的业务闭环很简单：管理员维护图书和读者 → 读者检索图书 → 读者借书（库存减一）→ 读者还书（库存加一）→ 逾期判断。真正值得往论文里写的不是这条主链，而是两个细节：一个是借书时的事务边界——先减库存再写借阅记录，两步必须同时成功或同时失败，否则会出现系统里记录显示已借出但实际库存没扣的脏数据；另一个是逾期状态的判定，不要在读者打开详情页时才去临时算，最好有一个定时任务（Spring 的@Scheduled或quartz）每天凌晨把due_time小于当前时间且return_time为 NULL 的记录刷成逾期。不是所有 zip 都自带这个定时任务，但它是一个容易出彩的答辩亮点，代价只是几十行代码。
3.3 登录拦截器和借书流程的代码骨架：能把业务讲清楚的三个关键类
对于“源代码+论文”这种交付物，评委最关心的其实不是你代码写得多精巧，而是你能不能口述清楚一条请求的完整路径。下面这条登录拦截器是最能体现“三层架构在跑”的示范代码，几乎可以原样用在系统里：
@Component public class LoginInterceptor implements HandlerInterceptor { // 不打眼皮名单，这些URL直接放行 private static final List<String> EXCLUDE_URLS = Arrays.asList( "/login", "/user/login", "/css/**", "/js/**", "/images/**" ); @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 先判断请求路径是否命中放行名单 String uri = request.getRequestURI(); for (String pattern : EXCLUDE_URLS) { if (uri.startsWith(pattern)) { return true; } } // 再判断Session中是否存在登录用户 Object user = request.getSession().getAttribute("LOGIN_USER"); if (user == null) { // 没登录则重定向到登录页，并携带原目标路径用于登录后跳回 response.sendRedirect(request.getContextPath() + "/login?redirect=" + uri); return false; } return true; } }这段代码的逻辑说明三句话能讲完：第一，静态资源和登录接口不进拦截器，否则登录页自己都无法加载；第二，登录凭证放在 Session 而不是 Cookie，避免“记住我”功能带来的 rememberMe 漏洞话题——毕设答辩不追求安全纵深，但也不能送上明显的把柄；第三，sendRedirect带了一个redirect参数，这是细节加分项，能让你在答辩时顺口说出“登录后回到用户原本想访问的页面”。这里的@Component只是给 Spring 容器注册 Bean，真正让它生效要去 SpringMVC 配置里注册拦截器并设置排除路径。如果你拿到的是 Spring Boot 版，则用WebMvcConfigurer的addInterceptors方法注册，效果一致但代码位置不同，论文里的截图要和你实际的代码结构吻合。
借书流程的 Service 层核心是一个事务方法，它比拦截器更能体现你对“事务”的理解。常见做法是先锁住图书行（SELECT ... FOR UPDATE或乐观锁版本号），再判断available_count是否大于 0，然后插入借阅记录并减库存，最后提交。这里有个血泪经验：如果你在BookMapper.xml里把库存扣减写成UPDATE book SET available_count = available_count - 1 WHERE id = #{id}，那并发下基本不会出问题；但如果你先SELECT available_count出来再在 Java 里减完再 UPDATE 回去，并发高一点就会出现库存减成负数。这不是算法问题，是你对 MyBatis 的更新语句是不是了解的问题。随便搜一下这种 bug 的报错现场，你会发现“库存负数”是图书管理系统里最经典的翻车点。
Controller 层相对简单，常见做法是接收页面参数，组装成实体，调 Service。唯一值得提醒的是“表单提交后的页面跳转”，如果你用了return "redirect:/book/list"这种写法，页面会重新请求列表接口，URL 也发生变化；如果写成return "book/list"，则是直接渲染视图。这两者的区别在答辩时经常被老师追问，尤其是“为什么新增图书后刷新页面会重复提交”这个问题，答案就在这两个返回写法的差异上。
4. 从 zip 到跑通：解压、建库、启动的最小路径
4.1 解压前的环境自检：JDK、Maven、MySQL 和 Tomcat 的版本对齐
你把 zip 解压之前，先打开命令行敲三个命令，把版本记录下来：
java -version mvn -version mysql --version这三个命令的输出决定了你后面要花多少时间调环境。最常见的匹配组合是 JDK 1.8 + Maven 3.6 + MySQL 5.7 + Tomcat 8.5。如果你的java -version显示是 17 或 21，那打开 pom.xml 确认一下maven.compiler.source和target是不是 1.8，如果是，建议直接装一个 JDK 8 来跑，不然会出现“不支持的 class file major version”报错。不建议在这个项目上尝试 JDK 17 运行老框架，Spring 5.x 在高版本 JDK 上跑，反射相关的坑你会踩到怀疑人生。
MySQL 版本这里有个取舍。如果你机器上已经装了MySQL 8.0，不必为了这个工程卸载重装。要注意两个点：第一，驱动版本要换，pom.xml里的mysql-connector-java建议升到 8.0.x，否则连 8.0 数据库会报Public Key Retrieval is not allowed；第二，驱动类名要从com.mysql.jdbc.Driver改成com.mysql.cj.jdbc.Driver，并加上?serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true这样的参数。这些改动都在jdbc.properties里，三行配置的事，但对第一次碰的人可能卡一晚上。
mysql --version如果显示V8.0.x，而 zip 里的library.sql是用 5.7 导出的，SQL 脚本本身大概率是兼容的，唯一要留意的是脚本头部有没有ENGINE=InnoDB AUTO_INCREMENT=... DEFAULT CHARSET=utf8;这种带版本特征的注释，有也没关系，直接导就行。反倒是如果 sql 文件里用了SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"或CREATE DEFINER=前缀，你需要用文本编辑器删掉这些头部的DEFINER段，否则非 root 用户导入时会报权限错误。
4.2 导入数据库和执行 sql 脚本：两种方式，结果完全一样
数据库这块我常用命令行方式，比在 Navicat 里点“运行 SQL 文件”更可控，出错信息更明显。下面是具体步骤：
# 1. 进入 MySQL 命令行 mysql -u root -p # 2. 创建数据库并导入脚本 mysql> CREATE DATABASE IF NOT EXISTS library_db DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci; mysql> USE library_db; mysql> SOURCE /path/to/your/sql/library.sql;如果用 Navicat，操作路径是“连接” -> 右键数据库 -> “运行 SQL 文件” -> 选择library.sql。两种方式等价，但命令行能看到“ERROR”明细，比如某张表已经存在导致的冲突，Navicat 在默认设置下可能会把错误吞掉，让你误以为导入成功。导入完成后，建议顺手做一次完整性验证，确认三张核心表存在并且有预置数据。常见做法是执行下面这组 SQL，结果集行数不为 0 就说明导入有效：
USE library_db; SELECT COUNT(*) FROM user; SELECT COUNT(*) FROM book; SELECT COUNT(*) FROM borrow_record;注意SOURCE路径里的斜杠方向，Windows 下也不要用反斜杠，MySQL 客户端认正斜杠。如果脚本里有中文注释，导入时报Unknown command乱码错，通常是脚本文件的编码和客户端字符集不一致，Windows 下用记事本另存为 UTF-8 无 BOM 格式可以化解九成这类问题。
4.3 改三处配置并启动 SpringMVC 项目：jdbc.properties 和 Tomcat 部署的细节
源码工程要跑起来，大多数 zip 只需要改三处配置。第一处是jdbc.properties，数据库连接串、用户名、密码以实际机器为准：
jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=123456参数说明：useUnicode=true&characterEncoding=utf8保证中文不乱码；serverTimezone=Asia/Shanghai是 MySQL 8.0 必加项，不写会在连接时报The server time zone value错；allowPublicKeyRetrieval=true是应对 MySQL 8.0 的 caching_sha2_password 认证插件，少了它会报“Public Key Retrieval is not allowed”。MySQL 5.7 环境可以去掉这后两个参数，保留也无害。密码就写成你本地 root 用户的真实密码，不要写成 zip 里默认的。
第二处是mybatis-config.xml里的下划线转驼峰配置，确保查询结果的列名能映射到 Java 实体的驼峰属性：
<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> <setting name="logImpl" value="STDOUT_LOGGING"/> </settings>mapUnderscoreToCamelCase的作用是把real_name自动映射为realName，你不写的话所有带下划线的字段查出来都是 null，这是 MyBatis 项目里最常见的“黑匣子”问题。logImpl在调试时打开，能让你在控制台直接看到 SQL 执行日志和参数绑定情况，排查“查出来了但数据不对”的问题时非常有用；跑通后可以去掉或改回默认。
第三处是 IDEA 里配置 Tomcat。操作路径：Run -> Edit Configurations -> 左上角 + 号 -> Tomcat Server -> Local，然后选择你的 Tomcat 安装目录。Deployment 选项卡里点 + 号选 Artifact，选中项目的war exploded（爆炸目录部署）。Application context 填/，这样访问地址就是http://localhost:8080，不用带项目名。这里有个细节很多人栽过：Artifact 如果选成war而不是war exploded，Tomcat 每次启动都会打包，改动 Java 代码后要手动 redeploy 窗口，开发效率很低。用war exploded配合 IDEA 的 Update（Ctrl+F10）能实现热更新，省去反复重启 Tomcat 的时间。
部署完成后启动 Tomcat，浏览器输入http://localhost:8080，如果看到登录页，说明这套 zip 已经跑通了。此时再回论文里核对截图里登录页的样式细节，比如按钮位置、表单字段，如果和你的系统长得不一样，强烈建议重新截图。
5. 图书管理系统 zip 避坑：5 个会让你当场翻车的运行细节
5.1 现象：Tomcat 启动成功，但访问页面 404
原因：这是 Artifact 配置问题，多数是 Deployment 里 Artifact 没选对，或者 Application context 设置成了/LibrarySystem，导致你访问根路径抱不到 index.jsp。还有一种情况是工程里缺失index.jsp或默认欢迎页配置，web.xml里漏了<welcome-file-list>段。
解决：先在浏览器试http://localhost:8080/项目名/，确认是不是 context path 问题。再检查src/main/webapp目录下是否有 index.jsp，如果没有，看web.xml里配置的欢迎页是哪个文件名。更暴力一点的做法是直接在地址栏输入http://localhost:8080/项目名/login，跳过欢迎页直达登录接口。注意：访问任何页面都先看 IDEA 里 Tomcat 的启动日志，只要日志里没有红色堆栈异常，就说明程序活得很好，404 几乎必然来自路由或部署路径。
5.2 现象：登录时提示用户名或密码错误，但数据库里明明有账号
原因：密码加密算法不一致。很多 zip 的sql脚本里预置的密码是 MD5 密文，而 Java 代码里用的是 BCrypt；或者反过来。两种密文格式都能往 255 长度的字段里放，普通肉眼看不出来，但校验函数会直接判 false。另一个隐蔽原因是数据库连接串的字符集不对，用户名里如果有特殊字符，在连接串参数不全时会乱码。
解决：先用 SQL 查出来原始密文长度和特征，MD5 是固定 32 位十六进制，BCrypt 以$2a$或$2b$开头且长度为 60。判断完算法后，去代码里找密码校验逻辑——如果是 SpringBCryptPasswordEncoder，就保持密文不动；如果是原生 MD5，把库里的密文重新用代码里的工具类加密后再 UPDATE。我在处理这类 zip 时的习惯是直接把数据库里的密码字段更新为新加密值，而不是改代码逻辑。更新方式如下：
UPDATE `user` SET `password` = MD5('123456') WHERE `username` = 'admin';注意这条 SQL 只适用于代码里用的是裸 MD5。如果代码用的是 MD5 加盐，或 BCrypt，这条 SQL 是无效的，就必须看代码里的加密工具类。
5.3 现象：图书列表页能打开，但“图书分类”那一列全是空
原因：表设计里book.category_id关联了category表，但 MyBatis 映射里没有做关联查询，或者关联查询的字段名和 Java 属性对不上。常见于 zip 里的 sql 脚本把category表漏掉了，建表只建了 user、book、borrow_record 三张，列表页查出category_id后没法 join 出分类名。
解决：先去数据库执行SHOW TABLES;看有没有category表；没有就翻代码里BookMapper.xml的 resultMap 或 SQL，确认它 join 的是什么表名。最省事的改法是把category_name直接冗余到book表里，删除category_id关联——毕设系统不需要范式上的完美，冗余字段换查询简单是非常务实的取舍。改完后记得同步修改论文中的数据库设计章节，表格字段说明里删掉category_id注释。
5.4 现象：借书时报错“库存不足”，但 book 表里 available_count 明明是正数
原因：典型的事务边界问题，也可能是你打开了两个页面同时操作同一本书，产生并发覆盖。但更多见的原因是代码里扣减库存的 SQL 带了多余的条件，比如WHERE id = #{id} AND available_count > 0，这条 SQL 在高并发下是正确的，但在测试环境、单用户操作时不可能失败。如果单用户也报库存不足，那说明传入的book_id有问题，或者你的BookMapper.xml里参数占位符写错。
解决：打开 IDEA 控制台或 MyBatis 日志，看那条 UPDATE 语句实际执行的参数是什么。常见的翻车点是把 Controller 里接收的bookId字符串没转 Integer 就直接传给 mapper，MyBatis 自动转换失败导致传入值变成 0。另一个隐蔽坑是借书时前端传的是表单里图书的目录序号（1,2,3）而不是数据库主键 id，查出来的当然不是那本书。这类问题打电话问不要，最简单的是在 mapper 接口方法上打断点，看入参再往下走——花两分钟看清参数，比猜半天强得多。
5.5 现象：中文显示成问号，从数据库到页面全都是乱码
原因：这是一个链条问题，数据库连接串缺characterEncoding=utf8会在 JDBC 层乱码；Tomcat 的 URI 编码没设 UTF-8 会在 GET 请求参数层乱码；JSP 页面头部没写pageEncoding="UTF-8"会在渲染层乱码；MySQL 客户端导入脚本时字符集不对会在存储层乱码。但凡中间有一环断了，你看到的就是问号。
解决：按顺序检查四个地方。第一，jdbc.properties的 url 里characterEncoding=utf8加上；第二，Tomcat 的server.xml里 Connector 节点加URIEncoding="UTF-8"；第三，所有 JSP 页面头部的contentType和pageEncoding都是 UTF-8；第四，导入 SQL 前先执行SET NAMES utf8mb4;。如果你用的是 MySQL 8.0，数据库表默认utf8mb4，但连接串里只写characterEncoding=utf8也能兼容。这是一个组合排查，不要改一个地方就重启 Tomcat 试，四个改完再启动。
提示：这个 zip 里如果自带
README.md或“部署说明.txt”，先花十分钟读完再动手。这类交付物里，作者踩过的坑往往会写进说明文件。但不要盲信说明文件里的版本号——他写的是他自己机器的环境，你的环境必须按实际输出为准。
6. 让论文和 demo 对得上：答辩前最后的验证清单
到了这一步，系统已经能跑了，但你要明白：毕业设计 zip 的最终目标是“让论文里说的和你当场演示的严丝合缝”。我见过太多现场翻车的案例，不是系统坏了，而是论文截图和实际操作对不上。比如论文里写“支持按分类筛选图书”，但你导入的 sql 里根本没有分类表；比如论文里截图显示读者列表有 20 个用户，你的库里只有 3 条预置数据——这类细节，认真评审的老师一眼就发现。
我的习惯是，答辩前按下面这个清单从头到尾过一遍，全程录屏保留：第一步，从 Tomcat 启动开始录屏，展示数据库连接的确认信息。第二步，用管理员账号登录，依次走“新增读者 -> 新增图书 -> 借书 -> 还书 -> 查询借阅记录”这条链路，确保每一步的页面跳转和论文里的需求分析对应上。第三步，退出登录，用新建的读者账号走一遍“注册 -> 登录 -> 检索图书 -> 借书”，这一步是为了验证非管理员链路也通。第四步，故意输错密码一次，展示错误提示。这四步录屏，比什么都管用。
另一个容易被忽略的是“预置数据”的数量。论文里的图表如果写了“系统现有图书 500 本”，而你库里只有十几条测试数据，答辩现场被要求演示分页功能时，第二页都翻不出来就很尴尬。参考做法是导入十几条测试数据后，用下面这组 SQL 快速灌一批假数据进book表：
USE library_db; INSERT INTO book (isbn, book_name, author, publisher, category_id, total_count, available_count, location) SELECT CONCAT('978-', LPAD(id + 1, 5, '0'), '-', LPAD(id + 2, 5, '0')), CONCAT('测试图书编号', id), CONCAT('作者', id), '人民邮电出版社', (id % 5) + 1, 5, 5, CONCAT('A区-', (id % 10) + 1, '排') FROM user;这段 SQL 的逻辑说明一句话：它借用了user表的自增 id 做序列，循环生成与用户数量相等的测试图书行，total_count和available_count均为 5，分类用 id 对 5 取模模拟五种分布。跑完后再看一下SELECT COUNT(*) FROM book;的行数，如果论文里写的是两百本，那你就再执行几次这条 INSERT，直到数量接近。这里唯一的注意点是借user表做笛卡尔积生成，如果 user 表行数太少，生成的图书数量就不够，可以先在 user 表里补几条测试用户。
最后，给出一个我在处理这类“源码+论文”zip 时的个人底线：论文可以借鉴前人的结构，代码可以复用现成的工程，但你一定要能不看任何资料，把这条借书的完整路径从头到尾讲清楚，包括数据库哪张表变了、日志里打印了什么、Session 里存了谁。这不是为了应付答辩，而是你以后写任何代码、排查任何问题，都逃不开的思维路径。把 zip 里的代码从头到尾读一遍，把它变成自己的东西，这本就该是毕业设计的真正意义。希望帮到你。
本文还有配套的精品资源，点击获取
