基于SSM的人事管理系统：从源码部署到Spring Boot迁移实战指南

简介：这是一套面向Java初学者与Web开发入门者的完整人事管理系统实战项目，基于SSM（Spring+SpringMVC+MyBatis）主流框架构建，覆盖企业级后台管理系统的典型业务场景。资源包共包含数百个文件（含源码、配置、JSP页面、SQL脚本及静态资源），以Java类文件、JSP视图页、XML映射配置、SQL建表脚本和jQuery前端交互代码为主，整体压缩后大小为59.18MB。已有1034人学习下载，适合作为课程设计、毕业设计或SSM技术栈综合实训案例。读者可直接导入IDEA/Eclipse运行，完整体验用户权限控制、部门/职位/员工全生命周期管理、公告发布与下载中心（含Spring MVC文件上传下载实现）等核心功能；数据库脚本位于hrm/src/main/webapp/db/hrm.sql，明确要求JDK 1.8与Tomcat 9环境，具备良好的工程结构与可调试性。

1. 认清这套系统的真面目：SSM人事管理系统的典型技术构成

拿到一个名为"基于SSM人事管理系统（源码+数据库脚本）.rar"的压缩包，你的第一反应大概率是赶紧解压、导入IDEA、点运行。但在我反复帮人处理过同类项目之后，我的建议是：先别急着启动，花一小时把整个系统的技术构成和业务模块搞清楚，后面能省下你一整天排错的时间。这类经典SSM人事管理系统的价值，从来不只是"能跑"，而是它把Java Web开发中最核心的一套技术栈完整串了起来。

先说技术栈。SSM不是某个具体框架，而是三个框架的组合：Spring负责对象管理和事务，SpringMVC负责Web层的请求分发，MyBatis负责数据库的持久化操作。打个比方，三者的分工就像一家公司的三个部门：Spring是后勤总管，所有对象的创建、依赖关系、事务边界都由它统一调配；SpringMVC是前台接待，所有HTTP请求进来，先由它解析、路由，再派发给对应的业务处理人；MyBatis是数据库翻译官，你把SQL告诉它，它负责把结果集变成Java对象，把你传参的对象变成SQL参数。三个框架各管一段，互相不越界，这就是SSM项目好理解的地方。

再说业务模块。人事管理系统不管具体叫什么名字，核心业务基本逃不出以下几块：员工档案管理，这也是整个系统中数据量最大、使用频率最高的模块，包括员工的基本信息、入职信息、岗位信息；部门管理，维护组织架构的树形结构，员工表通过部门ID与部门表关联；考勤管理，记录员工的出勤、请假、加班情况；薪资管理，根据员工的基本工资、岗位工资、考勤结果计算出应发工资，这个模块通常还带简单的统计功能；系统用户管理，也就是登录和权限管理，管理员、HR、普通员工能看到的页面和能执行的操作是不一样的。

很多初学者容易忽略的一点是：这套系统为什么到现在还有人用SSM而不是Spring Boot？一个原因是教学场景，很多学校的Java Web课程设计、毕业设计仍然指定SSM作为题目要求，因为SSM把配置过程完全暴露出来，学生能理解"原来是这么配出来的"；另一个原因是历史遗留项目，不少中小企业早年的内部管理系统就是SSM架构，后续一直在维护，新手入职后接手的第一份代码往往就是这类项目。所以学会看SSM项目，不是学一门过时的技术，而是在补Java Web最重要的一块底子。后面你去看Spring Boot的自动配置时，会发现它不过是把这些东西帮你做完了而已。

2. 解压源码包之后的第一步：环境对齐和项目导入

我见过太多人拿到源码包后直接双击pom.xml，结果报了一堆错，然后到处问"为什么我导入不成功"。绝大多数情况下，问题出在环境版本和原作者不一致，而不是源码本身有问题。SSM项目对环境的敏感度比Spring Boot高很多，尤其是JDK版本和Tomcat版本，稍微偏一点就可能起不来。

先说环境组合，这是经过大量项目验证比较稳妥的一套：

这个表不是随便列的。很多人卡在启动阶段，就是吃了版本不匹配的亏。比如用JDK 11去跑一个Spring 4的老项目，javax包的问题会让你怀疑人生；再比如MySQL 8.0下用旧驱动com.mysql.jdbc.Driver，直接就报ClassNotFoundException。所以导入源码之前，先把本机环境统一到上面这张表，能省掉相当一部分麻烦。

导入步骤本身并不复杂，但有几个细节容易漏。第一步，解压后先看目录结构，标准的Maven web项目一定是src/main/java、src/main/resources、src/main/webapp三块，如果看到的是.classpath、.project、WebContent这种目录，说明这是个Eclipse工程，在IDEA里导入方式略有不同，需要选New -> Project from Existing Sources之后在Project Structure里手动指定src/main/webapp为Web资源目录。第二步，File -> New -> Project from Existing Sources，在打开的文件选择框中直接定位到pom.xml所在目录，IDEA会识别为Maven项目。第三步，等待Maven完成依赖下载，这一步时间长短取决于网络，建议检查IDEA的Maven配置，确保settings.xml里配置了阿里云镜像，否则下载Spring相关依赖可能慢到你怀疑人生。

第四步是配置Tomcat。Run -> Edit Configurations -> 加号 -> Tomcat Server -> Local，在Deployment页签里添加Artifact，选xxx:war exploded这种模式，开发调试时用exploded比war方便很多，改完代码重新编译就能生效，不用整个重新打包。Application context一般设成/，如果你设成/hrms，那访问路径就要带项目前缀，很多新手在部署后死活访问不到页面，就是这里填错了。第五步，修改数据库连接配置。SSM项目的数据库配置通常在jdbc.properties或application.properties里，把用户名、密码改成你本地的，确认数据库名称和你导入的脚本一致。

做完这些之后，再执行数据库脚本、启动Tomcat。启动前建议先看一眼控制台有没有报错，Build -> Rebuild Project确保编译一次，避免因为旧class文件导致奇怪的问题。我个人的习惯是：每次拿到新项目，先按"编译 -> 启动 -> 看日志"这个顺序来，任何一步报错都先解决再往下走，不要一口气点完所有按钮然后面对一屏红色日志发呆。

3. 数据库脚本别急着跑，先读透它再动手

压缩包名字里专门强调了"数据库脚本"，说明这不是一个可选项，而是系统能不能跑起来的关键前置条件。但我要说的是：不要闭着眼双击脚本就执行，先把脚本内容从头到尾读一遍。一方面是为了确认表结构和业务逻辑是否对应，另一方面是提前发现可能存在的兼容性问题，免得导入时报错再回头补课。

一个典型的人事管理系统，数据库侧至少有这几张核心表。我拿最常见的表结构设计举例说明：

• t_emp（员工表）：主键通常用工号或自增id，常用字段包括emp_no（工号）、emp_name（姓名）、gender（性别）、birth_date（出生日期）、phone（手机号）、email（邮箱）、dept_id（部门ID，外键关联部门表）、position（岗位）、hire_date（入职日期）、status（在职/离职状态）。注意emp_no和status这两个字段很关键，工号是业务上唯一标识，状态字段用于员工离职后数据保留而不直接删除。
• t_dept（部门表）：id、dept_name、dept_leader_id（部门负责人，是一个员工ID）、parent_id（上级部门ID，用于组织树）。parent_id为0表示顶级部门，这种设计比单独一张层级表简单，对人事系统来说够用。
• t_attendance（考勤表）：emp_id、att_date（考勤日期）、status（正常/迟到/早退/缺勤/请假）、remark。这个表一天一个人通常一条记录，统计月出勤次数时按员工和时间范围group by即可。
• t_salary（薪资表）：emp_id、salary_month（工资月份）、base_salary（基本工资）、post_salary（岗位工资）、bonus（绩效奖金）、deduction（扣款）、total_salary（实发工资）。
• t_user（系统用户表）：id、username、password、emp_id（关联员工表）、role（角色，1管理员/2HR/3普通员工）、status。

下面是一段典型员工表的建表脚本，你可以对照着自己项目里的脚本看看是否一致：

CREATE TABLE `t_emp` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `emp_no` varchar(20) NOT NULL COMMENT '工号', `emp_name` varchar(50) NOT NULL COMMENT '姓名', `gender` char(1) DEFAULT '1' COMMENT '性别：1男 2女', `birth_date` date DEFAULT NULL COMMENT '出生日期', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `dept_id` int(11) DEFAULT NULL COMMENT '部门ID', `position` varchar(50) DEFAULT NULL COMMENT '岗位', `hire_date` date DEFAULT NULL COMMENT '入职日期', `status` int(1) DEFAULT '1' COMMENT '状态：1在职 0离职', PRIMARY KEY (`id`), UNIQUE KEY `uk_emp_no` (`emp_no`), KEY `idx_dept_id` (`dept_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8mb4 COMMENT='员工表';

这段脚本里有几个值得注意的设计细节。工号加了唯一索引uk_emp_no，避免系统里出现重复工号；dept_id加了普通索引idx_dept_id，因为按部门筛选员工是一个高频操作，不加索引在数据量大时会有明显性能问题；AUTO_INCREMENT=1001是为了让初始员工ID从1001开始，这样和工号做区分，避免ID暴露员工顺序。这些设计在实际开发中可能不算复杂，但对于一个教学性质的人事系统来说，已经足够规范。

脚本运行阶段最常见的坑，我按出现频率排一下：

1. MySQL版本兼容问题。老脚本如果用的是utf8字符集，在MySQL 8.0下运行没问题，但反过来，新脚本用了utf8mb4而你的数据库还是5.5，就会报字符集不支持。5.7以上基本都支持utf8mb4，建议优先用这个。
2. 排序规则冲突。创建表时如果指定了COLLATE，而导入的库默认排序规则不一致，会导致关联查询报错。解决办法是导入前先创建库时明确指定，比如CREATE DATABASE hrms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。
3. 外键约束导致导入顺序问题。如果脚本里有外键，必须先创建被引用的表（部门表），再创建引用表（员工表）。但很多教学脚本为了省事根本没建外键，只保留逻辑关联，这种反而导入更顺畅。

读脚本的另一个价值在初始化数据。通常脚本最后会插入管理员账号和几条测试数据，比如INSERT INTO t_user (username, password, role) VALUES ('admin', MD5('123456'), 1);，这时候你就能知道系统默认的登录账号密码是什么。很多人在系统能打开之后卡在登录界面，就是因为不知道初始账户密码。如果你的脚本里没有初始化用户数据，那就要在数据库里手动插入一条，否则登录功能再怎么调都进不去。

4. SSM整合的四个核心配置文件，跑不起来的问题九成出在这里

SSM项目的配置是整个系统的骨架，也是初学者最容易懵的地方。一个SSM web项目通常有四个核心配置文件，它们各管一段、层层嵌套。我在帮人排查项目启动问题时有一个经验：Tomcat能正常启动、页面能打开，说明web.xml基本没问题；一旦涉及页面之外的报错，八成是另外三个配置文件的细节没对上。

4.1 web.xml：整条链路的入口

web.xml是Java Web应用的入口，SSM的整合从这里开始。它要干三件事：配置Spring容器监听器、配置DispatcherServlet前端控制器、配置字符编码过滤器。核心片段长这样：

<context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <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> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <servlet> <servlet-name>dispatcherServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcherServlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

这个文件最大的坑在于<url-pattern>。/表示除了JSP之外的请求都交给DispatcherServlet处理，这种配置是SSM最标准的写法，但也意味着静态资源（JS、CSS、图片）必须先经过SpringMVC的静态资源映射处理，否则会被SpringMVC当成一个普通请求去匹配Controller，最后全部404。这个问题我会在下面踩坑部分详细说。

4.2 applicationContext.xml：Spring的容器配置

applicationContext.xml负责Spring容器层面的配置：包扫描（排除Controller）、数据源、事务管理、MyBatis整合。典型配置结构是这样的：

<context:component-scan base-package="com.hrms"> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.hrms.entity"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.hrms.dao"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>

注意context:component-scan这里有一个排除Controller的配置。原因是Spring容器和SpringMVC容器是两个容器，如果Controller被Spring容器也扫描进去，会出现事务失效、AOP代理异常、Bean重复创建等问题。这是一个非常隐蔽的坑，不报明显错误，但就是行为不对，很多人在Service层加事务不生效时根本想不到是这里的问题。

4.3 spring-mvc.xml：控制层的配置

这个文件管Controller层的注解扫描、视图解析器、静态资源映射和文件上传。核心内容：

<context:component-scan base-package="com.hrms.controller"/> <mvc:annotation-driven/> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> </bean> <mvc:resources mapping="/static/**" location="/static/"/>

视图解析器的prefix和suffix是一个高频出错点。如果你Controller里return "emp/list"，解析器会拼成/WEB-INF/views/emp/list.jsp，如果目录结构对不上，页面就是404。这个问题在导入别人项目时尤其常见，因为每个人的webapp目录结构都不一样，你必须对照实际目录来调整这个配置。

4.4 mybatis-config.xml：MyBatis的全局配置

MyBatis的全局配置一般比较简单，最核心的就两件事：开启驼峰映射和设置日志实现。驼峰映射这个配置非常关键，很多新手在Mapper里写了select *，发现返回的实体类属性全是null，就是因为数据库字段emp_name无法自动映射到Java属性empName。开启下面这行配置可以解决这个问题：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> <setting name="logImpl" value="STDOUT_LOGGING"/> </settings>

如果你拿到的项目没有mybatis-config.xml，而是把这些配置放在applicationContext.xml的sqlSessionFactory里，也是可以的，这类项目通常是在configurationProperties或configuration属性上做的配置。两类写法没有对错之分，但你要确认你的源码到底用的是哪一种，排查问题时不至于找错地方。

5. 登录与权限：一个安全的人事系统从哪里开始

人事管理系统涉及员工隐私数据，登录和权限是绕不开的核心模块。很多人觉得登录不就是比对一下用户名密码嘛，但在这个系统里，登录入口还承担了权限边界划分的任务：管理员能看薪资数据，HR能改员工档案，普通员工只能看自己的信息。如果登录环节出了问题，后面的一切都无从谈起。

5.1 登录流程的完整链路

一次登录请求从浏览器到数据库，在SSM项目里大概是这么走的：

1. 用户在login.jsp输入用户名密码，表单提交到/login接口。
2. DispatcherServlet拦截到请求，根据请求路径和参数匹配到UserController的login()方法。
3. Controller调用UserService.login(username, password)方法。
4. Service层先对密码做加密处理（老项目通常是MD5，严谨一点的会加盐），再调用UserMapper查询用户是否存在。
5. 查询成功则把User对象放进Session，并跳转到首页；失败则返回错误提示，留在登录页。
6. 用户每次访问受保护资源时，过滤器或拦截器检查Session里有没有登录用户，没有就重定向回登录页。

这里有一个典型的实现细节：密码入库前必须加密。很多学习项目的脚本里密码直接明文存了，这是不安全的，但你可以理解为教学项目为了演示方便。如果是自己维护，建议至少在DAO层或Service层做一次MD5加盐处理，千万不要明文存密码，也别在后端日志里把完整密码打出来。

5.2 拦截器实现登录校验

和Spring Boot不同，SSM的登录拦截通常靠SpringMVC的HandlerInterceptor来实现。下面是一个标准的登录拦截器：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { // 判断请求是否是Ajax请求 String requestedWith = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestedWith)) { response.setStatus(901); // 自定义状态码，前端判断后跳转登录页 } else { response.sendRedirect(request.getContextPath() + "/login"); } return false; } return true; } }

然后在spring-mvc.xml里注册这个拦截器，并配置哪些路径需要拦截、哪些放行：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/static/**"/> <mvc:exclude-mapping path="/captcha"/> <bean class="com.hrms.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

这里的<mvc:exclude-mapping path="/login"/>非常重要。如果不放行登录接口，用户没登录的时候会被拦截器拦住，被重定向到登录页，然后因为请求登录页也被拦截，直接形成死循环。这个问题我见过不止一次，让人崩溃的程度绝对是TOP3级别。还有个细节是登录接口的提交路径如果和跳转路径不一样，比如登录页是/login，表单提交的是/doLogin，那/doLogin也要放进白名单，否则永远登录不进去。

5.3 基于角色的菜单权限

系统要做好角色权限，单靠登录拦截还不够。人事管理系统里常见的角色是管理员、HR、普通员工，不同的角色看到的菜单和按钮不一样。SSM项目里实现方式通常有两种。一种是前端菜单按角色动态渲染，登录时把当前用户的角色信息放进Session，JSP页面里用<c:if test="${sessionScope.loginUser.role == 1}">控制菜单是否显示。另一种是后端接口做权限校验，在Controller方法上判断角色，权限不足时直接返回403。真实项目中两种配合使用，前端控制展示，后端控制数据安全。

我自己的建议是：如果你只是做课程设计或毕业设计，前端菜单按角色渲染加一个登录拦截器已经足够；如果是公司项目要上线，必须在每个写操作接口上做服务端权限校验。因为前端控制只是让用户看不到菜单，懂技术的人完全可以直接构造请求去访问后台接口，后端不校验等于门户大开。

6. 从"能跑"到"能上线"：我踩过最深的几个坑

这部分写给我自己，也写给所有曾经被SSM项目折腾到怀疑人生的人。这些坑是我和身边同事、同学在实际使用、部署这类项目时反复遇到过的，按严重程度从高到低排。

6.1 坑位一：Tomcat启动报ClassNotFoundException或NoClassDefFoundError

这个问题最常见的根源是项目依赖没有完整部署到Tomcat。直接表现是启动报错，要么找不到Spring的类，要么找不到MyBatis的类。在IDEA里点启动时，如果Tomcat的Deployment配置里没有正确添加Artifact，或者Artifact类型选错了，就会出现"代码在编译时正常，但运行时找不到类"的现象。解决方法是：File -> Project Structure -> Artifacts，把Available Elements里的xxx:war exploded加入左侧的Deployment包，让所有依赖jar包完整打包。然后回看Edit Configurations -> Deployment，确认添加的Artifact在前面配置的Context路径下。

还有一个很隐蔽的情况是Maven依赖下载不全，本地仓库里只有lastUpdated结尾的失败记录文件，没有真正的jar包。遇到这种情况，把本地仓库对应目录下的*.lastUpdated文件删掉，重新ReimportMaven项目。如果你用Maven彻底重新下载过还是报NoClassDefFoundError，检查是不是IDE的Build工具切换成了Gradle，导致Maven依赖没被正确引入。

6.2 坑位二：页面中文乱码，包括页面、控制台、数据库三处

SSM项目的中文乱码是个老传统。典型的情况有三种：页面显示乱码、控制台输出乱码、数据库存取乱码。三者的根源不一样，处理方式也不同。

• 页面乱码：检查JSP页面头部的<%@ page contentType="text/html;charset=UTF-8" language="java" %>，并且检查浏览器编码是否设置为UTF-8。如果有的话，确保web.xml里的CharacterEncodingFilter配置存在且url-pattern为/*，这个过滤器负责把请求参数从字节流解码成字符，不加这个过滤器，表单提交的中文大概率乱码。
• 控制台乱码：IDEA的控制台默认编码可能不是UTF-8，在Help -> Edit Custom VM Options里加上-Dfile.encoding=UTF-8，重启IDEA。
• 数据库乱码：检查连接URL，确认带上useUnicode=true&characterEncoding=UTF-8参数，同时确认表和库的字符集是utf8mb4或者utf8。比如：

jdbc.url=jdbc:mysql://localhost:3306/hrms?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai

如果你用的是MySQL 8.x，驱动类要改成com.mysql.cj.jdbc.Driver，并且URL中必须带serverTimezone，否则会报时区错误。老项目里写的是com.mysql.jdbc.Driver，这个驱动类在MySQL 8.x下已经废弃了。

6.3 坑位三：404和500，处理思路完全不同

启动成功后访问页面报404或500，很多人不喜欢看具体状态码，上来就问"为什么打不开"。这两个错误码的排查方向完全不同：

• 404：资源不存在。先判断是请求路径错了，还是Controller返回的视图前缀后缀和实际目录不匹配。请求路径对了但JSP找不到，多半是InternalResourceViewResolver的prefix/suffix没有对到视图目录。还有一种可能是SpringMVC把静态资源请求当成动态请求处理了，你要确认<mvc:resources mapping="/static/**" location="/static/"/>这个静态资源映射配置是否存在；没有这个配置，CSS、JS全部不可用，页面打开就是光秃秃的。
• 500：服务器内部错误，异常信息一定在Tomcat控制台。最常见的是Mapper的XML文件里SQL写错、字段或参数对不上、空指针注入失败。这种时候第一件事不是去改代码，而是去控制台找到Caused by那一行，问题根源百分之百在那里。我见过有人不看日志直接重写了整个Controller，结果发现只是SQL语句里一个字段名写错了。拿到错误日志后，对照mapper/*.xml里的SQL和实体类字段，逐一核对，问题很快能定位。

6.4 我给新手的排查顺序建议

根据我处理这类项目的经验，建议你按以下顺序排查SSM项目的所有问题：先看Tomcat控制台有没有启动异常，再看浏览器控制台和页面状态码，接着看IDEA右下角Maven是否还有依赖没加载完，最后看数据库连接和SQL是否正确。前两步能定位80%的问题。如果启动正常、访问页面有数据，但中文乱码或权限不对，再回到配置文件。不要一上来就怀疑源码有问题——这类项目能被分享出来，大部分是经过运行的，问题几乎都在环境配置。

7. 如果这个SSM项目要改造成Spring Boot，核心关注点在哪里

很多人跑通SSM项目后，下一步想的是"能不能把它改成Spring Boot？"这个问题值得专门聊聊，因为从SSM到Spring Boot的迁移过程，恰恰是把SSM整合原理学透的最佳验证方式。改造成本主要集中在四个方向。

第一个是依赖替换。SSM项目里的Spring、SpringMVC、MyBatis、Druid等依赖，换成spring-boot-starter-web和mybatis-spring-boot-starter两个Starter依赖就覆盖了大部分。但要注意，MyBatis的Starter在Spring Boot 2.x和3.x下的groupId不同，老项目从2.x迁移到3.x需要调整。

第二个是配置整合。SSM里的web.xml、applicationContext.xml、spring-mvc.xml、mybatis-config.xml四个配置文件，在Spring Boot里被合并成一个application.yml。对应关系如下：

比如SSM里配置的静态资源映射，在Spring Boot里你要实现WebMvcConfigurer的addResourceHandlers方法，或者直接用默认静态路径。拦截器的注册方式也从spring-mvc.xml变成了WebMvcConfigurer的addInterceptors方法。这种一一对应关系，如果你在SSM阶段认真看过配置文件，理解起来会非常快。

第三个是数据源和事务。SSM里手动创建的DruidDataSource，在Spring Boot里只要引入druid-spring-boot-starter，然后在application.yml里写上spring.datasource相关信息就完成配置。事务还是通过@Transactional注解，但Spring Boot会自动配置事务管理器，不需要手动声明。

第四个是启动类的结构。Spring Boot需要一个主启动类，标注@SpringBootApplication，它承担了SSM中ContextLoaderListener和DispatcherServlet自动装配的职责。你之前通过配置文件手动做的一切，Spring Boot都用自动配置帮你默认做好了，但如果你的项目有特殊需求，就要知道在哪个配置类里覆写默认行为。

如果你有空闲时间，我强烈建议你把这个SSM人事管理系统原封不动地改造成Spring Boot版本。改造时不要新起一个空项目重写，而是在现有代码基础上逐步替换依赖和配置，每替换一步就跑一次测试，确认Controller、Service、Mapper三层都没被破坏。这个过程会逼着你搞清楚很多以前没注意的细节，比如@MapperScan在哪里生效、@Transactional是否还能正常工作、JSON序列化发生了哪些变化。等你能把这个项目完整改成Spring Boot跑起来，你对这两套体系的理解会有一个非常明显的跃迁。

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