SSM图书馆借阅管理系统：从数据建模到借还事务的完整实现

简介：基于Java的图书馆借阅管理系统毕业设计资源包，面向计算机专业毕业生及SSM框架学习者，完整覆盖图书借阅业务从登录到归还的全流程。系统基于SSM框架搭建，包含读者与管理员双角色登录、图书模糊查询、借阅登记、归还管理、图书入库及用户信息管理等功能模块，可作为毕业设计与课程设计的直接参考。资源包共488个文件，以java源码、class字节码、html页面、css/js前端资源及xml配置文件为主，另含sql数据库脚本与项目工程文件，压缩包整体约24.5MB，结构清晰便于按模块查看。目前已有163人学习下载，适合需要快速理解SSM项目分层架构、复用业务代码与完成论文撰写的学习者。通过阅读源码与数据库脚本，可掌握图书管理系统的表结构设计、Controller层接口实现及前端交互方式，为后续扩展或答辩演示提供基础。

1. 这套 SSM 图书馆借阅管理系统：先看清六个模块再动手

java 毕业设计里，「图书馆借阅管理系统」是被选烂却依然容易翻车的题目。表面看只有登录、查书、借书、还书，实际拆开是用户登录、图书查询、借阅、归还、图书管理、用户信息管理六个模块，还要求读者和管理员两种身份在同一套系统里共存。这套基于 SSM（Spring + SpringMVC + MyBatis）的毕业设计源码包，控制器与业务类已经拆好：AccountController 管登录注册，UserInfoController 管用户信息，OrderInfoService 管借还核心链路，适合课程设计、毕业设计答辩和想快速搭一个 JavaWeb 完整项目的从业者。下文会从数据建模、权限控制、借还事务讲到部署避坑，照着能复现，也能讲清设计理由。

2. 数据建模与目录结构：六张业务表和四个 Controller 的分工

2.1 SSM 为什么是这类题目的默认答案

选 SSM 不是因为新，而是因为「任务书友好」。Spring 管对象和事务，SpringMVC 管请求路由，MyBatis 管 SQL 半自动映射，三者各管一段，模块边界清楚，答辩时每一层都能单独讲：请求先进 Controller，调 Service 里的方法，方法再走 Mapper 接口，SQL 写在 XML 里。相比 Spring Boot 的自动装配，SSM 里的连接池、事务管理器、扫描路径都要显式声明，配置繁琐一点，但配置本身就是答辩素材。

数据访问用 MyBatis 而不是 JPA/Hibernate，理由也简单：图书查询、借阅统计这类 SQL 变化多，XML 里写原生 SQL，模糊查询和连表一眼能看懂，导师追问时能白话说清。JPA 那种由框架生成SQL的做法，对毕业设计来说提问环节容易被动。

2.2 核心表设计：图书、用户、管理员、借阅四张必建表

对照摘要模块，这套系统的表可以拆成四张核心表和若干辅助表。核心表结构和字段命名我一般这么建：

CREATE TABLE `book_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `book_id` varchar(32) NOT NULL COMMENT '书号，用于模糊查询', `book_name` varchar(100) NOT NULL COMMENT '书名', `author` varchar(50) DEFAULT NULL, `publisher` varchar(80) DEFAULT NULL, `isbn` varchar(20) DEFAULT NULL, `price` decimal(10,2) DEFAULT NULL, `stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存量，借出时递减', PRIMARY KEY (`id`), UNIQUE KEY `uk_book_id` (`book_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `user_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `account` varchar(50) NOT NULL, `password` varchar(64) NOT NULL, `real_name` varchar(50) DEFAULT NULL COMMENT '读者姓名', `role` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0读者 1管理员', PRIMARY KEY (`id`), UNIQUE KEY `uk_account` (`account`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `order_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL COMMENT '读者ID', `user_name` varchar(50) DEFAULT NULL, `book_id` varchar(32) DEFAULT NULL, `book_name` varchar(100) DEFAULT NULL, `borrow_date` datetime DEFAULT NULL COMMENT '借阅日期', `return_date` datetime DEFAULT NULL COMMENT '还书日期', `is_returned` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0未归还 1已归还', `remark` varchar(255) DEFAULT NULL COMMENT '备注', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

book_info 表的关键设计是保留 book_id 与自增 id 并存，book_id 作为对外书号参与模糊查询，自增 id 作为内部主键；order_info 里冗余了 user_name 和 book_name 两个字段，虽然违反第三范式，但对毕业设计来说少写两次连表查询，列表页渲染也更省事，答辩被问到「为什么冗余」就答「读多写少，以空间换查询性能」。role 字段放在 user_info 里比单独建角色表更贴合当前需求规模，两种身份靠这个值区分即可。

2.3 从 class 文件名反推模块划分

拿到资源包时里面是编译后的 class 文件，但文件名已经把模块暴露得很清楚。我习惯先把类名按职责分组再对照功能清单：

按这个对应关系，包内结构还原后大致是 controller、service、dao（或 mapper）、entity 四层平铺。搭建自己的工程时按同样分包走，后期替换实现、加功能都不用动整体骨架。

2.4 一个可直接套用的 SSM 工程目录骨架

还原后的工程目录我会整理成下面这种结构，idea 或 eclipse 导入后不需要挪动源码位置：

library-manage/ ├── pom.xml ├── src/main/java │ ├── com/demo/library/controller # AccountController 等控制类 │ ├── com/demo/library/service # OrderInfoService 等业务类 │ ├── com/demo/library/dao # Mapper 接口 │ ├── com/demo/library/entity # BookInfo, UserInfo, OrderInfo 实体 │ └── com/demo/library/config # 拦截器、配置类 ├── src/main/resources │ ├── mybatis/mapper/ # 每个实体对应的 XML │ ├── jdbc.properties │ └── spring/ # spring-mvc.xml, spring-mybatis.xml └── src/main/webapp ├── assets/ # css/js，注意拦截器要放行 ├── jsp/ # 页面文件 └── WEB-INF/web.xml

pom.xml 依赖建议锁定三个版本组，最容易出问题的就是组合乱配：Spring 用 4.3.x 或 5.x 都行，但要和 JDK 匹配；MyBatis 用 3.4.x；连接 MySQL 的驱动按数据库版本选 5.1.x 或 8.x。新建工程时，先让一个查全部图书的列表页跑通，再往上面加登录和借还，能少很多排查时间。

3. 登录与权限：把读者、管理员两种身份收进 Session 与拦截器

3.1 AccountController：登录与注册的请求设计

登录模块的核心不是 SQL 而是「身份识别」。读者和管理员共用同一张 user_info 表，靠 role 字段区分；注册时默认写 0，管理员账号由管理端接口写入。控制器里的设计常见做法是这样：

@Controller @RequestMapping("/account") public class AccountController { private final UserInfoService userInfoService; public AccountController(UserInfoService userInfoService) { this.userInfoService = userInfoService; } @PostMapping("/login") public String login(String account, String password, HttpSession session, Model model) { UserInfo user = userInfoService.login(account, password); if (user == null) { model.addAttribute("error", "账号或密码错误"); return "login"; } session.setAttribute("loginUser", user); session.setAttribute("role", user.getRole()); if (user.getRole() == 1) { return "redirect:/admin/index"; } return "redirect:/index"; } @PostMapping("/register") public String register(UserInfo user, Model model) { user.setRole(0); boolean ok = userInfoService.createUser(user); if (!ok) { model.addAttribute("error", "用户名已存在"); return "register"; } return "redirect:/account/loginPage"; } @GetMapping("/logout") public String logout(HttpSession session) { session.invalidate(); return "redirect:/account/loginPage"; } }

这段代码的逻辑意图是：login 方法里把查到的完整 user 对象放进了 Session，而不只是账号名，这样后面借书、还书、显示当前用户信息都不需要再查库；role 单独存一份是为了后面拦截器里判断角色时少一次类型转换。register 强制 setRole(0)，能避免从前端表单直接传角色字段实现「注册成管理员」的漏洞。

参数说明：account 和 password 走表单 POST 提交；密码存库前至少做一次 MD5 或加盐哈希，答辩时被问安全问题时「不能明文存储」是底线答法。session.setAttribute 的 key 全工程要统一，我习惯固定叫 loginUser，拦截器里也读同一个 key，避免在某个控制器里改成 currentUser 导致后续校验全部失效。

3.2 用拦截器实现身份隔离

两种身份共存最容易翻车的地方是：读者登录后直接访问管理员页面。网上把这种漏洞叫「越权访问」，SSM 里对应的标准解法是 SpringMVC 拦截器。下面这段拦截器是可复用的通用写法：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String uri = request.getRequestURI(); // 登录注册相关接口直接放行 if (uri.contains("/account/login") || uri.contains("/account/register") || uri.contains("/assets/")) { return true; } Object loginUser = request.getSession().getAttribute("loginUser"); if (loginUser == null) { // 未登录跳回登录页 response.sendRedirect(request.getContextPath() + "/account/loginPage"); return false; } // 管理员接口还要再校验角色 if (uri.contains("/admin/")) { Object role = request.getSession().getAttribute("role"); if (!"1".equals(String.valueOf(role))) { response.sendRedirect(request.getContextPath() + "/index"); return false; } } return true; } }

这个拦截器设计成两级校验：第一级查有没有登录，第二级查访问的是不是 /admin/ 开头，配合 role 判断管理员权限。写进 spring-mvc.xml 时拦截路径写<mvc:exclude-mapping>比在代码里写字符串更直观，但代码里做的好处是别人拿到资源时不用猜哪些路径被放行了。注意放行 /assets/ 静态资源，这一步漏了，页面样式全部丢失，是很常见的问题。

3.3 用户信息管理与权限的配合

UserInfoController 负责读者的显示、录入、修改、查询、删除。管理员登录后可以通过列表找到任意读者，重置密码或者注销账号。这个模块实现时最影响体验的点是「查询带分页」，如果一次查出全表数据，数据量过千后页面直接卡顿。常见做法是给 Mapper 的查询手动加 LIMIT：

<select id="selectPage" resultType="com.demo.library.entity.UserInfo"> SELECT id, account, real_name, role, create_time FROM user_info <where> <if test="keyword != null and keyword != ''"> AND (account LIKE CONCAT('%', #{keyword}, '%') OR real_name LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY id DESC LIMIT #{offset}, #{pageSize} </select>

LIMIT 的两个参数由后台计算：offset = (pageNum - 1) * pageSize。这个方案性能不是最优（数据量大时深分页会慢），但对毕业设计这种量级完全够用。改页码时前端重新把 pageNum 传给控制器，后端重新查一次，逻辑简单、答不翻车。删除用户前要先检查他名下有没有未归还的借阅记录，这个约束写在哪一层要提前想好，放在 Service 里比较合理，Controller 只负责接收参数和返回视图。

4. 借阅归还核心链路：库存扣减、状态回写与模糊查询

4.1 图书查询：模糊查询的 SQL 写法与索引边界

图书查询模块要求「根据书号 BookID、书名 BookName 模糊查询，也可以全部查询」。前端是一个输入框加一个查询按钮，后台接收 keyword，拼进查询条件。这里的 SQL 写法决定了查询能不能命中字段：

<select id="searchBooks" resultType="com.demo.library.entity.BookInfo"> SELECT * FROM book_info <where> <if test="keyword != null and keyword != ''"> book_id LIKE CONCAT('%', #{keyword}, '%') OR book_name LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY id DESC </select>

注意两个细节。第一，主查询条件的两个 OR 会让复合索引失效，但 keyword 没有用前缀匹配，索引用不上，本质上就是一次全表扫描，表数据在几万条以下能接受；第二，如果想把「全部查询」和「关键字查询」分两个接口写也常见，但用一个 where 标签把空关键字吞掉更省事，后端一次调用覆盖两种情况。这里的 MYBATIS<where>会自动去掉第一个 AND，新手容易在条件前多写 AND 导致 SQL 报错，用 where 标签能兜住。

4.2 借阅流程：OrderInfoService 的事务边界

借阅不是简单的 INSERT，它涉及两张表的状态变更：order_info 里插入一条借阅记录，book_info 里把库存减一。两步要么都成功要么都失败，所以必须放在同一个事务里。OrderInfoService 里核心方法通常长这样：

@Service public class OrderInfoService { @Autowired private OrderInfoMapper orderInfoMapper; @Autowired private BookInfoMapper bookInfoMapper; @Transactional(rollbackFor = Exception.class) public boolean borrowBook(OrderInfo order) { // 1. 校验库存是否足够 BookInfo book = bookInfoMapper.selectByBookId(order.getBookId()); if (book == null || book.getStock() <= 0) { throw new RuntimeException("图书不存在或库存不足"); } // 2. 用条件更新扣减库存，防止并发超借 int rows = bookInfoMapper.decreaseStock(order.getBookId()); if (rows == 0) { throw new RuntimeException("库存扣减失败，请重试"); } // 3. 写入借阅记录 order.setBorrowDate(new Date()); order.setIsReturned(0); orderInfoMapper.insert(order); return true; } }

这里的关键是第 2 步那条 decreaseStock，对应的 SQL 必须带库存条件：

<update id="decreaseStock"> UPDATE book_info SET stock = stock - 1 WHERE book_id = #{bookId} AND stock > 0 </update>

UPDATE 语句里加 stock > 0 是防止超借的关键。两个读者同时借最后一本书时，数据库的行锁会让第二个 UPDATE 等第一个提交后再执行，此时 stock 已经是 0，条件不成立，受影响行数为 0，代码就走 throw。如果不加这个条件，两条借阅记录可能都插入成功，库存却变成负数，这是借阅系统最常见的生产事故。@Transactional 注解记得加 rollbackFor = Exception.class，因为 Spring 默认只对 RuntimeException 回滚，如果你的方法里 catch 住了异常并返回 false，事务不会回滚，库存照样扣。我一般会把异常直接抛出，由上一层控制器统一处理成提示信息。

4.3 归还流程：状态回写与库存回补

归还比借阅多一个前置判断：怎么知道该读者借了这本书？方案是查 order_info 里 user_id + book_id + is_returned=0 的最后一条记录。归还时把这条记录置为已归还，写还书日期，然后把库存回补。这个逻辑对应 OrderInfoService 里的 returnBook 方法：

@Transactional(rollbackFor = Exception.class) public boolean returnBook(Integer orderId, String remark) { OrderInfo order = orderInfoMapper.selectById(orderId); if (order == null || order.getIsReturned() == 1) { throw new RuntimeException("未找到有效的借阅记录"); } // 1. 更新借阅记录为已归还 order.setIsReturned(1); order.setReturnDate(new Date()); order.setRemark(remark); orderInfoMapper.updateById(order); // 2. 库存回补 bookInfoMapper.increaseStock(order.getBookId()); return true; }

returnBook 的参数设计我建议传 orderId 而不是再传一遍 user_id 和 book_id。原因有两个：前端操作目标明确，点击某条借阅记录直接带上 id；后端用 orderId 能查到完整记录，避免前端伪造 user_id 和 book_id 修改别人订单。库存回补的 increaseStock 就是 stock + 1，不需要带条件。

归还界面里「是否已归还」这一列，前端显示可以用 JSP/Thymeleaf 判断：

<td> ${order.isReturned == 1 ? '已归还' : '未归还'} 支出 </td>

如果是纯 JSP 环境写成<c:choose>标签也可以。注意 is_returned 字段在后端实体里命名不要叫 isReturned 直接用 returned，否则很多 JavaBean 工具类在 getter/setter 生成时会出歧义，这是踩过好多次的坑。

5. 避坑常见问题：部署报错与数据不一致的五个现场

5.1 MySQL 驱动版本不匹配导致的连接失败

现象：启动 Tomcat 后报ClassNotFoundException: com.mysql.jdbc.Driver或Communications link failure。

原因：MySQL 5.x 用com.mysql.jdbc.Driver，MySQL 8.x 驱动类名改成com.mysql.cj.jdbc.Driver，同时连接 URL 需要带时区参数。资源包里的 jdbc.properties 是编译时环境写的，本地装的是 MySQL 8.0 时，旧配置直接翻车。

解决：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=你的密码

改完记得把 pom.xml 里的 mysql-connector-java 版本同步到 8.0.x，版本不一致会运行到一半报Unsupported connection type。

5.2 页面正常打开但样式全丢

现象：登录页能显示 HTML，但按钮没样式，布局乱掉。

原因：拦截器把静态资源请求也拦截了，SpringMVC 的 DispatcherServlet 把 /css/* 和 /js/* 当成控制器路径去匹配，当然找不到，返回 404。这个问题的隐蔽性在于接口正常、页面源码也有链接，但资源响应是 404。

解决：拦截器里放行静态资源，或者在 spring-mvc.xml 里加<mvc:resources mapping="/assets/**" location="/assets/"/>，同时检查 JSP 页面的静态资源引用是否带了${pageContext.request.contextPath}前缀。不带上下文路径的引用在部署时一定找不到文件。

5.3 中文乱码：SQL 条件对但查不到

现象：模糊查询输入「三体」查不到，输入拼音或英文却能查到；新增图书后页面显示一串问号。

原因：Tomcat 默认编码不是 UTF-8，POST 请求的 body 解码和 MySQL 连接的字符集两边不一致。

解决：web.xml 里加编码过滤器：

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

配合数据库连接 URL 里的 characterEncoding=utf8，以及表结构里的 utf8mb4，三层一致才不可能乱码。注意 jdbc.properties 和 web.xml 两个地方都要配，只配一个都会有一个环节乱掉。

5.4 @Transactional 没有生效：方法内部调用自己人

现象：借阅时库存减了，但借阅记录没写进 order_info；异常时库存不回滚。

原因：Spring 事务是通过 AOP 代理实现的，同一个类里方法直接调用时走的是 this 调用，代理对象没有机会插入事务逻辑。常见写法是 OrderInfoService 里this.borrowBook(...)或者方法内部调同一个类的另一个 @Transactional 方法，事务会静默失效。

解决：事务方法必须由外部调用进入，Controller 调 Service 没问题，Service 内不要用 this 调用带事务的另一个方法。需要内部协作时拆成两个 Service 互相注入，或者直接把两段逻辑顺序写在同一个事务方法里。另外检查 spring-mybatis.xml 是否配置了<tx:annotation-driven transaction-manager="transactionManager"/>。

5.5 重复借阅与一票多借

现象：同一读者对同一本书反复点击借阅，产生多条未归还记录；库存显示还剩 1 本，实际上已经借出去 3 本。

原因：借阅前没查是否已有未归还记录，前端暴力请求或用户手动刷新导致重复提交。

解决：借阅方法开头先查一次：

OrderInfo exist = orderInfoMapper.selectUnreturned(order.getUserId(), order.getBookId()); if (exist != null) { throw new RuntimeException("该书尚未归还，不能重复借阅"); }

这个检查要和库存扣减放在同一个事务里。注意这是一个经典的「先查再写」并发问题，严格场景需要加唯一索引或锁，毕业设计做到事务内校验足以应付，答辩被问到时可以答「当前采用事务内先校验后写入，数据量增大时可加唯一约束兜底」。

6. 答辩与二次开发：分页改造、超期提醒和演示脚本

拿到这套系统源码后，与其直接交差，不如针对三个高频问法各做一个增量改造，既验证自己读懂了代码，答辩时也有话可说。

第一个增量是分页改造。系统里图书列表和用户列表大概率是整表输出，我给查询方法加一个 PageBean 工具类，把页码、每页条数、总记录数收进去，Mapper 的查询拼 LIMIT。改造的关键点是把「查列表」和「查总数」两个动作写进同一个 Service 方法，避免页面翻页时总数不一致。

第二个增量是超期提醒。借阅管理模块要求记录借阅日期，那么「借了 30 天没还」就是一种自然延伸。常见做法是借书时默认期限 30 天，归还列表页每次渲染时计算剩余天数，颜色区分正常和超期：

public long getRemainDays(OrderInfo order) { if (order.getIsReturned() == 1) { return 0; } Calendar cal = Calendar.getInstance(); cal.setTime(order.getBorrowDate()); cal.add(Calendar.DAY_OF_MONTH, 30); long diff = cal.getTimeInMillis() - System.currentTimeMillis(); return diff / (1000 * 60 * 60 * 24); }

这个方法挂在 OrderInfo 实体的扩展属性上，JSP 里直接调用，不动表结构。真正做定时任务扫描超期用户不是毕业设计重点，在查询时实时计算足够说明思路。

第三个增量是准备一份演示脚本。把六个模块串成一条完整链路：管理员登录，入库两本书，注册一个读者，用读者身份登录，模糊查询这本书，借阅，库存从 2 变成 1，再还书，库存恢复。每一步演示时说出对应 Controller 和 Service 的方法名。这套脚本能让你在答辩时不慌，也能顺带发现哪些功能链路其实是断的。

最后说一个我自己的习惯：每次拿到一份新的 SSM 工程，我会先花十分钟把 jdbc.properties、web.xml、spring-mybatis.xml 三个配置文件从头到尾读一遍，确认数据库、编码、事务三件套没有缺配置，再启动项目。这个习惯救过我很多次，因为多数所谓「跑不起来」的问题，根源都是这三处配置和本地环境不一致，而不是代码逻辑有 bug。希望这套图书馆借阅管理系统的拆解能帮你少走一段弯路，项目跑通了，原理也就通了。

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