简介：基于SSM框架的图书管理系统完整项目，适合正在学习Java Web进阶知识或准备课程设计、毕业设计的开发者。系统在业务上覆盖权限登录、读者管理、图书借阅与归还、邮件通知、答题互动等模块，技术上则贯穿Spring依赖注入、SpringMVC请求调度、MyBatis动态SQL配置，可直观看到三大框架如何协作完成业务链路。资源包共三个文件，包括工程源码、使用手册以及数据库初始化脚本，前者帮助分析代码结构与配置，后两者提供运行环境和数据准备，整体压缩包约九十一兆字节。目前已有三千二百五十四人学习下载，是不少学习者参考过的整合案例。对读者而言，通过阅读源码可理清分层架构、拦截器与事务控制等关键点，配合手册与脚本还能快速搭建运行环境并进行二次开发，能有效缩短从理论到实践的距离。

1. ssm框架的图书管理系统，值得下手的第一个理由：它是SSM整合的完整范本

如果你正在找一套能跑通的 SSM 图书管理系统，大概率不是为了“看看书怎么管理”，而是想弄明白 Spring、SpringMVC、MyBatis 这三个框架在一个真实项目里到底怎么互相配合。这套系统的核心价值在于：它不是一个只贴了 CRUD 代码的 demo，而是一个把配置、分层、请求流转、数据库操作全部串起来的标准工程。前端由 JSP 渲染页面，后端按 Controller-Service-Mapper 三层切分，你用任何一个 IDE 导入后都能启动、访问、断点调试。适合三类人：正在做毕业设计或课程实训的学生、想从 Servlet 转向 SSM 整合的进阶开发者、以及需要一套基础代码做二次开发（比如增加借阅规则、读者管理）的人。接下来我们先把它的工程骨架拆开。

2. SSM 整合骨架：从项目结构看懂 Spring + SpringMVC + MyBatis 的分工

SSM 整合最大的门槛不是某一个框架难学，而是三者叠加后“谁负责什么、配置写在哪、启动时加载顺序如何”容易混淆。这套图书管理系统的工程结构按功能分包，从根目录就能看出框架职责：Spring 管业务与数据、SpringMVC 管请求路由、MyBatis 管数据库访问。

2.1 项目目录设计与分层原则

这个图书管理项目采用标准的 Maven Web 工程结构。所谓“标准”指主包下按 controller、service、dao、entity（或 pojo）四层分包：controller 处理页面请求和参数绑定，service 做业务逻辑如借书校验、库存扣减，dao 即 MyBatis 的 Mapper 接口负责 SQL 操作，entity 对应数据库表。JSP 页面放在 src/main/webapp/WEB-INF 下，静态资源如 css、js、图片放 webapp/static，这样通过拦截器放行时路径也容易管理。

src/main/java/com/example/library ├── controller // BookController、UserController、BorrowController ├── service // BookService 接口 + Impl 实现类 ├── dao // BookMapper、UserMapper、BorrowMapper ├── entity // Book、User、BorrowRecord └── common // 统一返回结果、分页对象、异常处理 src/main/resources ├── mybatis // MyBatis 配置文件 ├── mapper // BookMapper.xml、UserMapper.xml 等 └── spring // applicationContext.xml、spring-mvc.xml src/main/webapp ├── WEB-INF │ ├── jsp // 图书列表、借阅记录、登录页 │ └── web.xml └── static // css、js、images

分包逻辑的出发点是：让每一层的依赖方向自上而下，controller 调 service、service 调 mapper，不反向引用。实际开发中改动最多的是 service 层，因为借书要考虑图书库存与用户借阅上限，还书要考虑逾期天数，这类业务规则必须沉淀在 service 而不是 controller，否则后期改需求会很痛。这套项目的 dao 层以接口加 XML 的方式定义，实体类与表字段一一对应。

2.2 核心配置职责：applicationContext.xml、spring-mvc.xml 与 web.xml 的边界

SSM 整合里最容易翻车的是“配置写错文件”。web.xml 是整个 Web 应用的入口，它负责启动 Spring 容器和 SpringMVC 容器。这里有一个关键约定：applicationContext.xml 配置 Spring 的全局内容，包括数据源、事务管理器、MyBatis 的 SqlSessionFactory、Service 层的扫描；spring-mvc.xml 只配置与 MVC 相关的内容，包括 Controller 组件扫描、视图解析器、静态资源放行。两者不能混为一谈。

<!-- web.xml：配置 Spring 与 SpringMVC 的加载 --> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring/applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring/spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

核心逻辑是 DispatcherServlet 拦截所有请求（/），再把请求交给 spring-mvc.xml 中定义的 HandlerMapping 定位到具体 Controller 方法。load-on-startup设 1 表示容器启动时就创建 DispatcherServlet，而不是等第一个请求到达才初始化，这对排查启动报错很重要。

在 spring-mvc.xml 中只做三件事：<context:component-scan base-package="com.example.library.controller"/>、配置视图解析器指定 JSP 路径前缀与后缀，以及放行静态资源。applicationContext.xml 则配置数据源（如 MySQL 的连接地址、账号密码）、SqlSessionFactoryBean 的 Mapper 文件位置、事务管理器，并且<context:component-scan base-package="com.example.library.service"/>只扫描 service 与 dao。如果扫描范围重叠或者全用默认扫描，轻则 Bean 重复，重则事务注解失效，这一点在后文避坑章节细说。

2.3 用 Maven 拉依赖：pom.xml 版本选择与冲突排查

SSM 项目依赖多，版本匹配是启动阶段最折磨人的点。我的习惯是先用 Maven 统一管理版本，spring 相关的四个核心包（spring-core、spring-webmvc、spring-jdbc、spring-tx）必须保持相同版本，否则会出现类加载冲突或 NoSuchMethodError。数据库驱动、MyBatis 与 mybatis-spring 桥接包的版本也要匹配：MyBatis 3.4.x 配合 mybatis-spring 1.3.x 可正常运行，如果换成 mybatis-spring 2.x，搭配方式基本不变，但要注意官方包路径调整。

<!-- pom.xml 关键依赖（版本以 BOM 或 properties 统一控制） --> <properties> <spring.version>5.2.22.RELEASE</spring.version> <mybatis.version>3.5.6</mybatis.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>${mybatis.version}</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.0.6</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.29</version> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>1.4.2</version> </dependency> </dependencies>

注意 PageHelper 的 starter 是 Spring Boot 版本，若在传统 SSM 中使用，应引入pagehelper核心包并在 MyBatis 配置中追加插件，否则分页不生效。依赖冲突排查的做法：启动时若出现 ClassNotFoundException，先执行mvn dependency:tree看是否存在两个版本的 spring-web；出现Invalid bound statement则检查 Mapper XML 路径是否在编译后存在于 classes 目录，以及 mapper 接口是否被包扫描覆盖。

3. 数据库设计与图书 CRUD 落地：从建表到 Mapper 映射

图书管理系统最核心的资产是数据模型。很多学习者拿到项目直接改代码，却忽略表设计决定业务实现难度这一前提。这套系统的表数量不多，通常就图书表、读者/用户表、借阅记录表，外键关系尽量用逻辑关联而不是物理外键，项目跑起来更省心。

3.1 图书管理系统的数据模型：book、user、borrow_record 三表结构

这张三表模型几乎覆盖进销存和借阅管理的基本形态。图书表负责存静态信息，用户表存读者资料，借阅记录表承担借书/还书的状态流转。设计时注意：图书表要有独立的逻辑删除字段deleted，而不是物理删除记录。借阅记录表要有borrow_time和return_time，其中return_time允许为空，空值表示尚未归还，这是后续统计逾期与在借数量的判断依据。

CREATE TABLE `book` ( `id` INT NOT NULL AUTO_INCREMENT, `isbn` VARCHAR(20) DEFAULT NULL, `book_name` VARCHAR(100) NOT NULL, `author` VARCHAR(50) DEFAULT NULL, `publisher` VARCHAR(80) DEFAULT NULL, `category` VARCHAR(30) DEFAULT NULL, `stock` INT DEFAULT 1 COMMENT '馆藏数量', `borrowed_count` INT DEFAULT 0 COMMENT '已借出数量', `deleted` TINYINT DEFAULT 0 COMMENT '0未删，1已删', PRIMARY KEY (`id`), KEY `idx_book_name` (`book_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL, `password` VARCHAR(64) NOT NULL COMMENT '加密后密码', `real_name` VARCHAR(30) DEFAULT NULL, `max_borrow` INT DEFAULT 5 COMMENT '最大借阅数量', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `borrow_record` ( `id` INT NOT NULL AUTO_INCREMENT, `book_id` INT NOT NULL, `user_id` INT NOT NULL, `borrow_time` DATETIME NOT NULL, `return_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_book_user` (`book_id`,`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

两个细节值得注意：stock表示馆藏总量，borrowed_count表示当前已借出数量，实际可借数量通过stock - borrowed_count计算，比每次实时 count 借阅记录更高效。user.max_borrow是业务规则的数据库载体，调整单人可借数量不用改代码。字符集统一使用 utf8mb4 而不是 utf8，否则插入生僻字或特殊符号容易丢字符。

3.2 MyBatis Mapper 映射：XML 写法与参数绑定细节

这套项目的 Mapper 层用 XML 实现动态 SQL，比注解方式更适合复杂条件查询。以图书查询为例，最常踩的坑是“条件为空时 SQL 拼接多出一个 WHERE 或 AND”。MyBatis 的<where>标签会自动去掉多余的AND和OR，这是 SSM 图书管理项目中必须用熟的关键字。

<!-- BookMapper.xml：动态多条件查询 --> <select id="searchBooks" parameterType="map" resultType="com.example.library.entity.Book"> SELECT * FROM book <where> <if test="bookName != null and bookName != ''"> AND book_name LIKE CONCAT('%', #{bookName}, '%') </if> <if test="author != null and author != ''"> AND author = #{author} </if> <if test="category != null and category != ''"> AND category = #{category} </if> AND deleted = 0 </where> ORDER BY id DESC </select>

代码逻辑说明：<where>标签自动处理首个条件前的AND，避免 SQL 语法错误。所有参数通过#{}传入，MyBatis 会将其转化为预编译的?占位符，可有效规避 SQL 注入。parameterType="map"是因为调用方可能只传部分字段，用 Map 不必定义专门的查询对象。

参数说明：LIKE CONCAT('%', #{bookName}, '%')推荐写法，不要在 Java 代码里拼好%再传，否则遇到特殊字符时容易出问题。deleted = 0放在<where>内，保证任何查询都自动过滤已删除数据。如果只想查某本具体的书，book_name的等值匹配比LIKE性能更好，这一点在索引使用时很重要。

3.3 Service 层事务边界：为什么数据源配置只写一半会静默失败

SSM 图书项目新增图书时需要校验 ISBN 是否重复，这时候事务的边界就显得很关键。常见的新手认知是：MyBatis 的 SQL 执行成功就万事大吉，但实际场景里 SQL 执行成功只是第一步——比如新增图书时向 book 表插入一条记录，同时往某个统计表写入日志，第二条 SQL 失败时第一条必须回滚。

@Service public class BookServiceImpl implements BookService { @Autowired private BookMapper bookMapper; @Override @Transactional(rollbackFor = Exception.class) public void addBook(Book book) { int count = bookMapper.countByIsbn(book.getIsbn()); if (count > 0) { throw new RuntimeException("ISBN已存在"); } bookMapper.insertBook(book); } }

逻辑说明：@Transactional(rollbackFor = Exception.class)明确声明所有异常都触发回滚，不写rollbackFor时默认只回滚 RuntimeException，受检异常不会自动回滚，这是数据不一致的高发源头。Service 方法内部先查重再插入，两个操作同处一个事务，避免并发下重复插入。

参数说明：抛出RuntimeException是事务回滚的触发条件，如果这里改成返回false或抛出普通 Exception，事务不会回滚。强调一点：@Transactional放在 Service 实现类的具体方法上，不要放在接口上，因为某些动态代理机制对接口注解的识别不稳定。

4. 把功能做实：图书搜索、分页与借还操作的实现过程

CRUD 只是骨架，图书管理系统真正让用户觉得“能用”的功能是搜索、分页和借还操作。这三个功能最考验对 SSM 请求流转和 SQL 细节的把控。

4.1 分页查询：PageHelper 与手动 Limit 的选择

分页有两条路：一条是引入 PageHelper 插件，在 Service 层调用PageHelper.startPage(pageNum, pageSize)后紧跟一条 Mapper 查询，插件自动拦截并生成带 LIMIT 的 SQL 并注入总数统计；另一条是手动计算offset = (pageNum-1)*pageSize后传入 Mapper。这套图书系统我默认推荐 PageHelper，因为它在查询逻辑不变的情况下能快速完成分页，但如果你为追求可控性，手动 Limit 也完全可以接受——只要记得 count 查询与数据查询分开写。

// BookController：分页查询图书列表 @RequestMapping("/list") public String list(@RequestParam(defaultValue = "1") int pageNum, @RequestParam(defaultValue = "10") int pageSize, Model model) { PageHelper.startPage(pageNum, pageSize); List<Book> bookList = bookService.queryAllBooks(); PageInfo<Book> pageInfo = new PageInfo<>(bookList); model.addAttribute("pageInfo", pageInfo); return "book/list"; }

PageHelper.startPage只对紧随其后的第一条 Mapper 查询生效，所以调用后不要插入其他 SQL 操作。PageInfo封装了 total、pageNum、pageSize、pages 等字段，JSP 端可以按需取用。页面底部渲染上一页/下一页时，注意参数拼接：我用${pageInfo.prePage}和${pageInfo.nextPage}时要校验首尾边界，否则第一页点“上一页”会跳到第 0 页，这在用户实操中很戳信任感。

手动分页的 SQL 写法是：limit #{offset}, #{pageSize}，但要注意 offset 在 XML 里传入时已经是计算后的整数，不要在 SQL 里再乘一次。用 PageHelper 时如果出现“分页不生效”的翻车，绝大多数原因是 mybatis-spring 的版本与 PageHelper 插件的拦截器方式不匹配，后文避坑章节单独展开。

4.2 模糊搜索：书名、作者、ISBN 的组合条件处理

真实检索场景下用户很少一次性填满所有搜索条件，更多是只输入一两个字。组合条件的关键在于：前端表单可能有空值，后端 Controller 的@RequestParam可能没有传入对应参数，这时直接用getParameter会拿到 null 并拼进 SQL，产生与预期不符的结果。正确姿势是前端传空串，后端对空串做统一容错。

@RequestMapping("/search") public String search(@RequestParam(required = false) String bookName, @RequestParam(required = false) String author, @RequestParam(required = false) String category, Model model) { Map<String, Object> condition = new HashMap<>(); condition.put("bookName", bookName == null ? "" : bookName.trim()); condition.put("author", author == null ? "" : author.trim()); condition.put("category", category == null ? "" : category.trim()); List<Book> list = bookService.searchBooks(condition); model.addAttribute("bookList", list); return "book/list"; }

代码逻辑：required = false让 SpringMVC 接收不到该参数时不报 400，而是注入 null。传入 Mapper 前统一处理为合法值，避免 XML 里写太多判空。trim()去掉首尾空格是一门细节，用户从输入框粘贴内容时常带不可见字符，去掉后搜索命中率明显提升。搜索结果默认不分页会导致数据量大时页面卡顿，我一般会配合 4.1 的分页逻辑复用同一套查询。

4.3 借书/还书：库存校验与状态流转的实现

借书不是简单 insert 一条记录，它要同时满足三个条件：用户存在、在借册数未达上限、图书可借库存足够。真正写业务时，用户很少先查询一遍再点借阅，往往是直接提交，因此校验必须写进 Service 层。常见错误是把校验放 Controller 里，换一套前端访问方式就绕过了逻辑。

@Transactional(rollbackFor = Exception.class) public void borrowBook(Integer bookId, Integer userId) { Book book = bookMapper.selectByIdForUpdate(bookId); if (book == null || book.getDeleted() == 1) { throw new RuntimeException("图书不存在或已删除"); } if (book.getStock() - book.getBorrowedCount() <= 0) { throw new RuntimeException("库存不足"); } int activeBorrows = borrowRecordMapper.countActiveByUserId(userId); if (activeBorrows >= userMapper.findById(userId).getMaxBorrow()) { throw new RuntimeException("已达借阅上限"); } bookMapper.increaseBorrowedCount(bookId); borrowRecordMapper.insert(new BorrowRecord(bookId, userId, new Date(), null)); }

代码逻辑：selectByIdForUpdate使用悲观锁锁住图书行，避免同一本书同时被多人借出时超借，这是“并发场景下库存不够分”的兜底做法。借出数量通过stock - borrowedCount判断，而不是直接用stock > 0，否则已借出的数量没扣除会导致借阅总数超过馆藏。countActiveByUserId统计该用户尚未归还的借阅记录，与user.max_borrow比较时注意需查询用户基本信息的额外代价。

借书时的数字变化有两处：book 表的borrowed_count加 1，以及 borrow_record 表插入一条记录。必须放在同一事务里，顺序是先扣减、后插入，如果顺序反了，插入失败时扣减落库会造成数据错乱。还书时反向操作：borrowRecordMapper.updateReturnTime(recordId, new Date())并把对应图书的borrowed_count减 1，注意还书操作要取最近一条未归还记录，避免用户对同一本书借了两次后还错记录。

5. SSM 整合避坑自查：那些让你翻车的配置与依赖问题

SSM 这个组合运行起来路径必然经过配置文件，任何一个环节断开都会导致启动失败或请求异常。遍历这套系统的完整运行环境后，我把高频翻车按“现象—原因—解决”整理出来，新手照着排查能少走弯路。

5.1 现象：Service 自动注入为 null，调用方法抛空指针

原因：<context:component-scan>扫描的 base-package 过窄或者根本没有覆盖到 service 实现类，Spring 容器中没有生成 Service Bean。很多时候 people 忘记在 applicationContext.xml 里加扫描标签，只配了数据源和 SqlSessionFactory，导致@Autowired注入时找到不到 Bean。

解决：确认 applicationContext.xml 中显式声明<context:component-scan base-package="com.example.library.service"/>，且 base-package 必须指向 service 包所在位置，不能写成com.example.library.controller。写完配置后启动项目看控制台日志，搜一下Creating service之类的输出，确认 Bean 被实例化。

5.2 现象：启动时报Failed to configure a DataSource或连接超时

原因：数据源配置选择错误或变量占位没解析。常见于 jdbc.properties 文件未加载、driver-class-name等关键项名称敲歪，比如把driver-class-name写成driverClassName就无法绑定。MySQL 8.0 版本驱动时驱动类是com.mysql.cj.jdbc.Driver，而 5.x 是com.mysql.jdbc.Driver，两者混淆必挂。

解决：在 applicationContext.xml 中按下面方式引入 jdbc.properties，并显式指定class为org.springframework.jdbc.datasource.DriverManagerDataSource或 druid 数据源。配置里的 URL 务必写成jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8mb4，不写characterEncoding容易出现中文乱码，不写useSSL=false在 MySQL 8 下可能报 SSL 连接告警。

5.3 现象：前端通过 AJAX 拿不到返回值，console 一直解析失败

原因：SpringMVC 方法返回Map或List时缺少@ResponseBody或工程缺少 Jackson 依赖。传统 SSM 中@ResponseBody需要 jackson-databind 等依赖，否则返回数据无法序列化为 JSON，前端拿到的是 500 错误页或空体。

解决：pom 中引入com.fasterxml.jackson.core:jackson-databind这一依赖；Controller 方法上加@ResponseBody或类上直接加@RestController。注意spring-mvc.xml里要开<mvc:annotation-driven/>，否则 SpringMVC 默认不启用 Jackson 转换器，加注解也会失效。

5.4 现象：部署到 Tomcat 后访问页面 404，但启动无报错

原因：项目没有正确编译为可运行的 Web 模块，或web.xml里 DispatcherServlet 的<url-pattern>配置把 JSP 请求也拦截了。Tomcat 找不到 JSP 页面，直接走到兜底 404。还有一种情况是 SpringMVC 的视图解析器前缀路径配错，导致返回的视图名指向了不存在的目录。

解决：先确认 JSP 是放在src/main/webapp/WEB-INF/jsp下并且被 Maven 打包。视图解析器配置请这样写：<property name="prefix" value="/WEB-INF/jsp/"/><property name="suffix" value=".jsp"/>；JSP 放在WEB-INF目录外也能被直接访问，但不如放里面安全，后文登录拦截会展开。若/拦了一切，在 spring-mvc.xml 中写<mvc:resources mapping="/static/**" location="/static/"/>放行静态资源，否则连 css、js 都会被拦下来。

6. 让系统更稳：事务、慢查询与登录拦截的进阶调校

系统能跑起来只是开始，要放到实训环境或正式环境里被人连续点几十次还不出错，还得做三件进阶的事：严格事务、优化查询、守住权限。

6.1 事务控制策略

把事务注解细化到具体业务方法。借书与还书这类写操作无条件用@Transactional(rollbackFor = Exception.class)；单纯的列表查询、单条详情查询建议不加事务，避免给数据库增加无谓的锁。需要多条 SQL 联合更新时再开启事务。注意 Spring 的代理机制：同一个类内部调用带事务注解的方法，事务不生效。比如BookServiceImpl中 a 方法调同一个类的 b 方法，b 上的事务会被忽略，正确做法是独立封装或注入自身代理，我通常把写操作整合到一个门面类处理，比如BorrowFacade。

6.2 慢查询排查

图书列表页点击一次要做一次 count 加一次数据查询，MySQL 拿到模糊搜索条件很容易全表扫描。对常见搜索字段book_name和author建索引，并且在 SQL 执行前使用EXPLAIN SELECT * FROM book WHERE book_name LIKE '关键字%'检查是否命中索引。要留意 LIKE 以%开头时，即使有索引也无能为力。真遇到搜索慢到闪红，直接用前缀索引或考虑 MySQL 全文索引。从设计上想，这份资源中idx_book_name索引只能加速前缀匹配，带%开头时我可以把首字符相同的量控制住，比如建议用户输入至少前两个字再搜。

6.3 登录拦截与静态资源放行

未登录用户理论上不能进入 /book/list、/borrow/* 等路径。用 SpringMVC 拦截器实现要比在 JSP 里频繁判断 session 干净得多。继承 HandlerInterceptorAdapter 或实现 HandlerInterceptor 接口，在 preHandle 方法里检查 session，若为空则重定向到 /login。配置时注意把/login、/static/**排除，否则登录页自己也进不去，css、js 被拦后又出现页面裸奔状态。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

代码逻辑：request.getSession().getAttribute("loginUser")从回话中取登录对象，当用户未登录时会被重定向到登录页。response.sendRedirect重定向路径需要拼接request.getContextPath()，否则部署在带上下文路径的正向时跳转可能指向错误地址。登录成功后记得在业务代码中主动设置 session 属性，否则这个拦截器永远认为你未登录，我在这里吃过亏。

写完登录拦截后顺手做了一件很提效的事：用日志打印拦截器是否命中，验证期里每次点请求都能在控制台看到遍历路径，排查“为什么页面能访问却跳登录”这类问题时快很多。从那以后我每次调 SSM 项目都强制走一遍“检查拦截器 + 验证事务 + EXPLAIN 走索引”这三步，任何从毕业设计来的历史项目都能在半天内确认是否达到交付标准。这套 SSM 图书管理系统也是一样，按上面的思路从头到尾把配置、业务、安全三步走通，剩下的工作就是按你自己的业务需求改字段和页面了，希望帮到你。

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