SSM与Spring Boot彻底讲透：区别、联系与迁移方案

很多人学到Java后端的时候，都会经历一个特别拧巴的阶段：先照着教程搭了个SSM项目，配置文件写了一堆，好不容易跑起来，然后又听说现在企业里都在用Spring Boot，于是开始怀疑人生——SSM是不是白学了？Spring Boot是不是把SSM替代了？这两个东西到底什么关系？

说实话，这个问题很有代表性，也是Spring相关面试里经常出现的“概念题”。它看起来简单，但能把两者关系说得清楚的人，远比我以为的少。很多人面试时只能说一句“SSM是三个框架，Spring Boot是一个新框架”，然后就卡住了。这篇文章我就用实际开发的经验，把这两个概念拆开揉碎讲清楚，顺带给你一套可以直接用的“Boot版SSM”迁移方案。

如果你是刚学完SSM，准备做毕设或者找实习的Java开发者，这篇文章会帮你把知识串起来；如果你已经在用Spring Boot，但对底层还停留在“能跑就行”的状态，这篇也能帮你补上那块缺失的认知拼图。

1. SSM不是“一个框架”，而是三个框架的组合

1.1 先认识三件套各自的角色

SSM这个名字本身就是个简称，全称是Spring + SpringMVC + MyBatis。它不是一个框架，而是三个框架组成的一套技术栈。很多人把SSM当成一个整体去学，结果学到后面出了问题都搞不清是哪一层出的问题，这就是因为一开始没搞清楚三件套的分工。

Spring管的是“对象工厂”。所有Service、Dao、工具类，都交给Spring容器去创建和管理。你在代码里只需要用注解或XML声明一下依赖关系，Spring会自动把对象注入进来。这解决的是“类与类之间耦合太重”的问题，你可以把它理解成一个中央仓库：谁需要什么，不用自己造，喊一声仓库管理员就行。

SpringMVC管的是“HTTP请求分发”。浏览器发来一个请求，SpringMVC的DispatcherServlet接到后，根据URL找到对应的Controller方法，执行完后把返回值再包装成JSON或页面返回。简单说，它是后端对外接待员，负责把用户的请求翻译给后端逻辑处理。

MyBatis管的是“数据库访问”。它是一套持久层框架，负责把Java对象和数据库表映射起来。你写SQL，它把结果集映射成对象；你传对象，它把参数填进SQL。和Hibernate那种“全自动”的ORM不同，MyBatis保留了对SQL的完全控制，复杂报表、多表关联、分页优化这些场景下特别好用。

这三个框架各管一段，组合起来正好覆盖了经典三层架构：Controller层（Web接入）、Service层（业务逻辑）、Dao层（数据操作），中层关系的粘合剂就是Spring的IoC容器。

1.2 没有Spring Boot之前，SSM是怎么“组装”的

在Spring Boot出现之前，搭建一个SSM项目是个体力活。我记得2016年前后做这类项目，新开一个工程要先创建好几个XML配置文件，目录结构也得自己一点点对。每个文件都不可或缺却极易写错，我曾因为漏写一行组件扫描，整整排查了一下午才找到原因——这种经历恐怕老后端都深有体会。

一个典型的SSM项目，至少要有下面这些配置文件：

src/main/java ├── com.example.controller ├── com.example.service ├── com.example.mapper src/main/resources ├── jdbc.properties # 数据库连接参数 ├── mybatis-config.xml # MyBatis全局配置 ├── spring-context.xml # Spring核心配置（数据源、事务） ├── spring-mvc.xml # SpringMVC配置（扫描controller、视图解析） └── webapp/WEB-INF/web.xml # 部署描述符，启动时加载Spring容器

以典型的jdbc.properties为例，里面也就是一些数据库连接信息，但配合一堆XML配置才能让Spring容器知道这些参数该用在哪里。开发时改个数据库密码，还得确认所有文件里的引用都同步更新了，相当繁琐。更别提每次发布前要打好WAR包、部署到外部Tomcat的步骤。

这套东西的问题，一句话概括就是“能跑，但太累”。框架本身没有问题，问题在于集成成本和不必要的重复劳动。也正是这些痛点，催生了Spring Boot的诞生。

2. 再看Spring Boot：它到底“替你做”了什么

2.1 核心观点：Spring Boot不是替代SSM里某个组件的“新框架”

很多人一听到“Spring Boot”，直觉反应是“又多了一个要学的框架”。其实不是，Spring Boot不是像MyBatis、SpringMVC那样负责具体某一层工作的框架，它更像是一个“集成底座”和“自动装配器”。

你可以这么理解：Spring Framework是发动机，SpringMVC是变速箱，MyBatis是车轮，而Spring Boot是一键启动系统。发动机、变速箱、车轮还是那些零件，但Spring Boot通过“约定优于配置”的方式，替你把它们自动组装好了。它并没有替换掉Spring MVC的请求分发能力，也没有消灭MyBatis的SQL控制力，更没有取代Spring容器本身。

所以严格来说，Spring Boot不是“新框架”，而是“基于Spring Framework的一整套快速开发方案”。它解决的问题，是“怎么让Spring项目更快地搭起来、更方便地跑起来”。它既可以是单体项目底座，也可以用于微服务场景，本质上不挑项目规模。

2.2 “约定优于配置”：它替你做了哪些决定

SpringBoot 最核心的设计哲学就是“约定优于配置”。什么意思？框架默认帮你假定了一套最常规的项目结构：启动类放在根包下、资源文件放在resources目录、配置文件叫application.yml、默认端口8080……只要不违反这些约定，你基本不用写一行大段配置。

这套机制落到代码上，主要是几个关键组件的配合。首先是spring-boot-starter依赖：每一个starter都是一份“依赖清单”和配置逻辑的打包，引入它就相当于一次性引入一组经过兼容性验证的依赖。其次是自动配置类，框架通过@EnableAutoConfiguration的机制，扫描classpath下的依赖，再结合@ConditionalOnClass之类的条件注解，决定“装载哪些默认配置”。最后就是application.yml，它取代了绝大部分旧XML配置，把数据源、端口、上传限制等等集中在一个人类可读的配置文件里。

举个例子，你想开启一个Web项目，只需要自己加一个spring-boot-starter-web依赖，启动后内嵌Tomcat立即生效。以前的Web配置需要部署到外部Servlet容器，现在这一切被封进jar包，运行java -jar便一键启动。你根本需要自己处理web.xml、spring-mvc.xml，该用的组件已经在自动配置里默认装配好。如果默认行为不满足需求，再通过少量配置去覆盖。

所以Spring Boot最大的价值在于“减少配置决策点”。它不是在技术能力上碾压了SSM，纯粹只是把使用SSM（或使用Spring全家桶）的过程大幅简化了。

2.3 Spring Boot不是只能做微服务

我经常看到有人把Spring Boot和微服务体系扯在一起，认为Spring Boot就是为了微服务而生的。这个说法不完全对。Spring Boot可以支撑一个独立的小服务，也可以一个包含多模块的系统整体运行，它本身只是一个应用框架。

真正让微服务落地的是Spring Cloud，那又是一套基于Spring Boot的更高层封装，包含服务注册、配置中心、网关、熔断等组件。Spring Boot就是“底座”，Spring Cloud负责“连接多个底座”。理解这一点后，你就不会把“单体SSM”和“微服务Spring Boot”当成对立面去理解了。

3. 本质关系：SSM是Spring Boot里的一个子集

3.1 两者的对应关系，一张表看明白

这里直接给出我对这两个概念关系的结论：你完全可以基于Spring Boot搭建一个“SSM架构风格”的项目——Web层用SpringMVC，持久层用MyBatis，对象管理交给Spring容器。Spring Boot并不会逼你不许用MyBatis，也不要求你抛弃SpringMVC。也就是说，SSM里的组合能力，是Spring Boot体系下的一个常规子集。

比如说，Spring Boot项目里你可以引入mybatis-spring-boot-starter，Mapper接口照常使用。实际的SpringMVC在后台照常处理请求，只是因为自动配置和启动内嵌Web容器，你已经不用手写web.xml和spring-mvc.xml了。所以“SSM会过时吗”这个问题，准确说应该是“手动配置SSM的繁琐时代过时了”，而三件套本身依然是SpringBoot项目的常见组成。

看这个表格，两种选型的差别会清晰很多：

3.2 别把“Spring”和“Spring Boot”当成两个并列框架

我在网上看过大量文章，标题写着“Spring vs Spring Boot”，点进去发现是把Spring Framework和Spring Boot放在了对立位置。其实这两样从来不是对立关系。

Spring Framework是底层基础设施，包括IoC容器、AOP、事务、事件等，至今仍然是所有Spring生态的中枢。Spring Boot是在Spring Framework外面又包了一层，让你能“傻瓜式”地使用Spring的能力。所以你看源码时会发现：一个Spring Boot项目启动后，Spring容器的初始化、Bean的装配、AOP代理的生成，这些南均来自Spring Framework本身的力量，Boot只是把“等待你去手工装配”的部分自动化了。

换个说法可能更容易理解：Spring Framework是操作系统，Spring Boot是基于系统预装的“应用商店+全套驱动”。应用商店里提供的应用（比如MVC、JPA、Security）依然需要系统支持才能运转，但用户再也不用自己一个个去装驱动和配置环境。

面试时如果被问到“SSM与Spring Boot的区别和联系”，一个比较稳的回答思路是：先说SSM是三个框架的组合，Spring Boot是基于Spring Framework的自动化集成的开发基底；再说“联系”在于——Boot项目里依然可以沿用SSM的分层架构和组件选型；最后说“区别”在于配置方式、启动方式、部署方式及学习视角的转换。框架定位和配置自动化才是核心分歧，而不是组件技术本身的价值削减。

4. 从SSM“改造”到Spring Boot：配置对比与实操

4.1 依赖声明对比：从散装到“starter”

实操最能说明问题。假设以前用传统SSM搭一个带MyBatis的Web项目，pom里大概会是这么一坨依赖：

<!-- 传统SSM依赖，数量多且需要自己维护版本 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>5.3.x</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.3.x</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.x</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.0.x</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.x</version> </dependency>

每个依赖的版本号都要自己查，还要担心版本兼容性问题——Spring 5.3和MyBatis 3.5是否兼容、mybatis-spring版本对不对，都是实际改SSM项目时最头疼的“版本黑洞”。

改成Spring Boot以后，优先引入parent管理和两个starter依赖，就能替代过去大半的手工依赖维护工作：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> <relativePath/> </parent> <dependencies> <!-- Web功能：含SpringMVC + 内嵌Tomcat + Jackson等 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis接入Spring Boot --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>3.0.3</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> </dependencies>

理论上我不再需要为每个依赖逐一挑版本号了，因为parent管理了版本；MyBatis starter则把我需要的mybatis核心包、mybatis-spring、自动配置类和相关Bean全部装配好。这就是“依赖管理和集成成本”的直观差异。

4.2 配置和启动方式对比：少了哪些XML，多了一个启动类

传统SSM里那一大堆XML，在Spring Boot项目里几乎全被替换掉了。以数据源配置为例，以前我只有一个固定的jdbc.properties文件，也需要在spring-context.xml手动引入并交给DataSource；而Boot里只需要一句application.yml就能完成：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/demo?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.demo.entity configuration: map-underscore-to-camel-case: true

这套配置的核心逻辑是：Spring Boot通过DataSourceAutoConfiguration读取spring.datasource.*属性创建数据源；MyBatisAutoConfiguration读取mybatis.*属性配置Mapper扫描、XML映射位置和驼峰转换等。所谓“自动配置”并不是魔法，本质就是当classpath下存在相关类时，自动将这些配置属性里的值绑定到默认的体系Bean中。

启动类也简洁得惊人，整个项目的入口就这一个文件：

import org.mybatis.spring.annotation.MapperScan; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication @MapperScan("com.example.demo.mapper") // 相当于原来mybatis-spring里的mapper扫描配置 public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }

一个@SpringBootApplication注解，集成了自动配置、Spring根配置和组件扫描三件事。以前Spring根容器扫Service层、SpringMVC子容器扫Controller层的分工模式，现在统一由启动类所在包的扫描范围托管。如果你的工程遵守“启动类放根包、业务分包清晰”的约定，扫描规则基本不需要操心。

4.3 一个最小“Boot版SSM”Demo，以及三个常见坑

如果要快速搭一个可运行的Demo，我建议按这个步骤走：

1. 打开 start.spring.io ，选Maven、JDK版本（Boot 3.x用JDK17+），依赖只勾Spring Web，生成压缩包解压导入IDE。
2. 在pom里再加mybatis-spring-boot-starter和MySQL驱动依赖，按上文写application.yml。
3. 建实体类、Mapper接口、XML或注解SQL、Service、Controller。Controller和传统SSM里写得几乎没区别。
4. 启动类上加@MapperScan，指向实际的Mapper包路径，然后运行main启动，访问接口验证。

看着简单，实际操作时有几个坑我几乎每次都会遇到，这里提前排一下：

• 数据源依赖只引一个就好。如果同时引入druid-spring-boot-starter和spring-boot-starter-jdbc，可能会出现数据源Bean重复定义的警告，甚至启动报错。默认情况下引入druid starter后，记得在配置里显式指定spring.datasource.type或使用druid的专有前缀配置项，避免与默认HikariCP冲突。
• mapper-locations的路径要跟实际XML目录一致。很多人习惯把XML放在src/main/resources/mapper下，但忘了配置mybatis.mapper-locations: classpath:mapper/*.xml，启动时不报错，调用时却抛出“Invalid bound statement (not found)”的异常，这个排查起来很恼火。
• 如果用的是Spring Boot 3.x，注意包名从javax.*迁移成了jakarta.*。你在老文章里抄代码时，那些javax.validation、javax.servlet的导入，都要改成jakarta.*前缀，否则编译都无法通过。

一旦这些坑踩过一遍，你大概率会非常习惯Spring Boot的清爽结构。很多老项目里动辄几十个配置类的沉重感，如今已经缩减到一个yml文件加少量配置类。

5. 面试和实操中关于这两个概念的常见坑

5.1 “学SSM还有用吗”和“Spring Boot会不会取代SSM”

这个问题在我的私信里出现频率超高，可以排进Java初学者恐惧榜前三。我的答案一直是：一定要学，而且要把SSM这套组合的原理学透，但没必要再花时间手动组装一套SSM骨架。

原因不复杂。Spring Boot的自动配置虽然省事，但它掩盖了很多底层细节。比如你知道项目里出现@RestController时，是谁把JSON序列化器配好的吗？你知道事务失效的常见原因有哪些吗？这些知识，不亲手搭几遍SSM、不亲手配置过SpringMVC和MyBatis的人，往往理解得很浅。所以学习阶段SSM是必经之路；实践阶段直接用Spring Boot才是现代效率。

至于“会不会取代”，更精确的说法是“手写XML集成方式基本上淡出历史舞台”，而SpringMVC、MyBatis这些技术本身依然活跃。Spring Boot并没有把SpringMVC删除，而是让它自动化运行了。它的Web表现层依旧由DispatcherServlet处理，持久层你可以继续选MyBatis。所以你完全不必要产生“以前学的全废了”的失落感。

5.2 常见问题速查表：版本、多项目登录、项目结构

这里我再把几个后台被问得比较多的相关话题，集中整理成一张速查表，希望能帮大家省一点搜索时间：

这里面有两个点值得再展开说一下。首先是版本问题。为什么我会单独提醒Boot 3.x不要随意切？因为有一次我在老项目里升级Boot版本，结果一堆依赖的javax导入要改成jakarta，还有一些第三方starter的兼容版本还没跟上，光是编译修复就花了一整天。如果生产环境没到非升不可的地步，升级框架版本要控制节奏，最好先在一个小模块里验证。

另外是“多个SpringBoot项目一次登录”这个问题，从热词出现的频率来看，现在做前后端分离和微服务的同学确实多。这里想提醒的是，登录状态是客户端会话层面的东西，不该让每个后端服务各自维护Session，否则A服务登录B服务不认，体验很割裂。实际项目中比较稳的做法是：登录态统一存到Redis，或者用JWT携带用户标识，网关层统一鉴权。记得设置Token过期和续签策略，别让用户隔10分钟就掉线一次。

5.3 怎么选型：我的个人建议

如果你正在纠结毕设或简历项目到底用什么，我的态度非常明确：

学原理用传统SSM，做项目用Spring Boot。毕设如果题目要求“前后端分离”，就选择Vue3+Spring Boot的组合；如果题目限定“SSM”，也可以在Boot里复刻SSM风格——引入MyBatis，沿用Controller-Service-Mapper分层，你在答辩时完全能说清楚“底层用的还是SpringMVC和MyBatis，只是用Spring Boot做了自动装配”。

我见过太多人毕设题目写的是“基于SSM的某某系统”，但pom里还真的手动配了一堆传统依赖——这不是不能跑，而是把自己逼回2016年的开发效率里去了。反过来如果你在真实开发中开口闭口“SSM”，别人反而会觉得你还在维护老古董。正确的态度是把SSM当成技术体系里的“组合拳”，把Spring Boot当成出拳更顺滑的新擂台，二者并不互斥。

最后说一点我自己的实操感觉

我刚从SSM转Spring Boot的那段时间，最大的问题不是理解不了自动配置，而是“控制感”突然消失了——从前XML里写什么我全知道，现在很多配置被自动装配接管，代码突然变得不“透明”，那种感觉挺难受的。

后来我摸索出一个笨办法，就是遇到不了解的自动装配时直接去读starter里的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，看看它加载了哪些配置类，再点进去逐个看条件注解。这一套下来，那些“偷懒”的自动配置就再也瞒不住你了。这个方法也推荐给你：学Spring Boot时别只停留在“能跑”，多看一眼自动配置类，你对Spring的理解会比多数人扎实很多。

我始终觉得，SSM和Spring Boot的关系其实并不玄妙：一个是手搓时代的直接标准组合，一个是自动化时代的集成入口，Spring Framework本身则像根茎一样把二者串联在一起。把这个关系理清了，往后学Spring Cloud、学源码，你的地基都会稳固得多。