先问个问题你有没有见过这种情况招聘软件上写着熟悉SSM框架优先面试官却问你Spring Boot的原理你打开某培训机构的课程目录前面几章是SSM后面几章是Spring Boot到你真正做项目了发现网上教程全是Spring Boot。于是你就懵了——这两个到底什么关系是同一个东西吗SSM被淘汰了吗我要不要先学SSM再学Spring Boot这个问题我在带新人时几乎每次都会被问到今天就把它一次说清楚。我先给一个结论SSM和Spring Boot不是对立的两个框架SSM是三个框架的组合Spring SpringMVC MyBatis而Spring Boot是基于Spring生态的一套快速开发脚手架。它们之间的核心关系可以概括为四个字——底层相通形态不同。换句话说SSM是把三个框架手动拼起来用Spring Boot是把Spring那套东西自动配好再用。Spring Boot并没有废除SSM里的任何核心概念而是把SSM时期那些让人头皮发麻的配置工作用自动化和约定取代了。这篇文章适合所有在学Java后端、准备实习、或者已经在用Spring Boot但没搞清楚它跟SSM关系的人。我会从三个框架各自的职责讲起把配置对比、代码对比、迁移思路全部拆开最后附上一些我实际踩过的坑和面试答题的建议。1. 先搞清楚SSM到底是哪三个东西拼起来的SSM是Spring、SpringMVC、MyBatis三个框架的缩写。很多人天天说我在用SSM但你要是问他Spring和SpringMVC的边界在哪里或者MyBatis到底解决了什么问题他可能说不利索。我先用大白话把三者拆开。1.1 Spring管对象的大管家Spring最核心的武器是两个IoC控制反转和AOP面向切面。IoC翻译成人话就是以前你要用一个对象自己new现在你告诉Spring我需要一个某某类Spring创建好对象、把依赖关系也处理好再交给你。你不需要关心它什么时候创建、怎么创建。这就像你去餐厅吃饭不用自己去买菜洗菜切菜只需要跟服务员说来一份宫保鸡丁后厨自然会准备好。餐厅后厨就是Spring容器你的需求就是Bean定义。AOP解决的是另一类问题有一些逻辑是横跨很多业务方法的比如日志记录、权限校验、事务管理。你不可能在每个方法里都写一遍开始记录日志-执行你的逻辑-结束记录日志。AOP允许你把这些通用逻辑抽取出来声明在这些方法执行前/后自动执行这段通用逻辑。还是餐厅的例子每桌客人来了都要倒水、上餐具、结账时打小票——这些跟具体点什么菜无关但每个客人都要经历。把这些固定流程抽出来由餐厅统一执行就是AOP的思路。SSM里的Spring就是承担这个大管家的角色。它管理者Service层、DAO层的对象处理事务控制权限。这是整个SSM的基础另外两个框架都要挂靠在它上面。1.2 SpringMVC接待HTTP请求的前台SpringMVC是Spring在Web层的一个模块专门处理浏览器发来的HTTP请求。它的核心流程是请求到达后由前端控制器DispatcherServlet接收然后根据URL找到对应的Controller方法执行完业务逻辑后把返回结果交给视图解析器渲染成页面或JSON响应。我常说SpringMVC是前台接待因为它不关心你的数据库怎么查、你的业务规则是什么它只负责接收请求、找到对应的人处理、把结果送回去。它解决的痛点是在它出现之前Java Web开发中处理请求要么写原生的Servlet一个请求一个Servlet类非常繁琐要么用Struts2配置复杂、入侵性强。SpringMVC用注解方法级别的映射把开发Web接口这件事变得非常清爽。1.3 MyBatis操作数据库的翻译官MyBatis是一个持久层框架它的职责是处理Java对象和数据库记录之间的映射。你在Java里定义了一个User对象数据库里有一张user表你写一条SQL把表里的数据查出来MyBatis帮你把结果集自动转换成User对象。为什么要用MyBatis而不是直接用JDBC因为JDBC的模板代码太多了加载驱动、创建连接、准备PreparedStatement、设置参数、执行查询、遍历ResultSet、手动封装对象、关闭连接。每一步都要写而且还得处理异常。MyBatis把这些样板代码全部封装掉你要做的核心事情就两件写SQL、写接口方法。这也是MyBatis和Hibernate这类全自动ORM框架最大的区别——MyBatis把SQL的控制权交给你适合SQL复杂、需要精细化调优的项目。SSM里的三个框架职责划分得非常清楚框架分层定位核心职责Spring容器层管理对象生命周期、依赖注入、事务管理SpringMVCWeb层接收HTTP请求、参数绑定、响应返回MyBatis持久层SQL执行、结果集映射、数据库操作这三个组件各管一段通过Spring将它们串联起来形成一个完整的请求→Controller→Service→DAO→数据库→响应的调用链路。这就是SSM的完整面貌。2. 传统SSM让人头疼的三座大山配置、依赖、部署讲完了SSM是什么接下来讲为什么大家后来都转向Spring Boot。不是SSM的理念错了而是SSM的落地体验太差了。我总结了三大痛点每一个都劝退过无数开发者。2.1 第一座大山配置多到能写出一本小册子一个标准的SSM项目光配置文件至少要有这么几个web.xml配置DispatcherServlet、过滤器、监听器spring-config.xml配置组件扫描、数据源、事务管理器springmvc-config.xml配置注解驱动、视图解析器、静态资源处理mybatis-config.xml配置别名、插件、Mapper扫描还有连接数据库的jdbc.properties我放一段当年的真实配置让你们感受一下。先看web.xmlweb-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd version3.1 servlet servlet-namedispatcherServlet/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-valueclasspath:springmvc-config.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcherServlet/servlet-name url-pattern//url-pattern /servlet-mapping context-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-config.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener /web-app再看springmvc-config.xml的一部分context:component-scan base-packagecom.example.controller/ mvc:annotation-driven/ bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views// property namesuffix value.jsp/ /bean mvc:default-servlet-handler/然后是spring-config.xmlcontext:component-scan base-packagecom.example.service/ context:property-placeholder locationclasspath:jdbc.properties/ bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName value${jdbc.driver}/ property nameurl value${jdbc.url}/ property nameusername value${jdbc.username}/ property namepassword value${jdbc.password}/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ /bean你以为这就完了没有。MyBatis的Mapper接口要扫描事务管理器要配置tx:annotation-driven/要开启如果你用了分页插件还得给MyBatis再加一个插件Bean。这一整套配置项目结构还没搭起来人先写了两个小时XML。而且里面任何一个BeanID写错或者依赖关系没配对启动直接就报错排查半天。2.2 第二座大山依赖你手工管理版本冲突靠缘分那时候用Maven虽然不用手动下载jar包了但每个jar包什么版本、兼容不兼容、要不要排除传递依赖全得自己操心。Spring Framework要拉一堆依赖SpringMVC和Spring的版本必须对齐MyBatis还要配合对应的mybatis-spring包。你用一个第三方库它传递依赖进来另一个版本的Jackson跟项目里已有的Jackson冲突启动时各种NoSuchMethodError这种问题我在2016年排查过无数个。Spring Boot解决这个问题的方式很简单它提供了一个经过官方测试、互相兼容的依赖版本集合你只要引入一个spring-boot-starter-web它自动把Spring、SpringMVC、Jackson、Tomcat等Web开发需要的全套依赖都带进来版本也已经锁定好了你不需要关心它们之间的兼容性。2.3 第三座大山部署链路长跑起来费劲SSM时代项目打包方式是war包。你要把项目打成war放到外置Tomcat的webapps目录下启动Tomcat然后项目才能跑。这意味着你要单独装一个Tomcat还有可能遇到Tomcat版本和项目不兼容IDE里调试时还要配置External Tomcat启动慢热部署配置不好用服务器上要发布新版本得把war包传到服务器重启一次Tomcat对比一下Spring Boot它把Tomcat直接内嵌进应用了。你打出来的是一个可执行的jar包命令行java -jar app.jar直接就起来了。服务器上不用装Tomcat开发环境和生产环境的行为完全一致。这个体验差异用过的人都知道有多爽。3. Spring Boot凭什么能降维打击拆穿自动配置的老底很多人把Spring Boot当成一个全新框架其实不是。Spring Boot的本质是基于Spring Framework的一套快速开发框架它没有创造新的编程模型而是做了三件关键的事起步依赖Starter管理依赖、自动配置Auto Configuration消灭繁琐XML、内嵌容器简化部署。逐一拆开看。3.1 起步依赖把全家桶打包发给你你在SSM里要手动汇集的依赖大概有十来个spring-core、spring-context、spring-beans、spring-web、spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、jackson-databind等等。在Spring Boot里引入一个依赖就全有了dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency注意这个坐标里没有指定version原因是项目父级已经引用了spring-boot-starter-parent版本被统一管理了。如果要用MyBatis再塞一个starterdependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.2.2/version /dependency这个starter的定位就是我要用MyBatis请把MyBatis和它与Spring整合需要的一切都给我并且把版本都配好。这个设计对我这种依赖洁癖的人来说体验是质的飞跃。3.2 自动配置约定优先于配置Spring Boot启动时会扫描所有依赖里的META-INF/spring.factories文件里面有大量的AutoConfiguration类。以Web开发为例ServletWebServerFactoryAutoConfiguration会自动内嵌一个Tomcat实例DispatcherServletAutoConfiguration会自动注册DispatcherServlet和SpringMVC的核心组件DataSourceAutoConfiguration会读取application.properties里的数据库配置自动创建一个数据源Bean。这背后的判断逻辑依赖一组条件注解。比如ConditionalOnClass表示classpath里存在某个类才启用这个配置ConditionalOnMissingBean表示容器里没有这个Bean才帮我创建。Spring Boot运用这些注解实现了你缺什么它自动给你补上你自己有它就尊重你的配置。这就是为什么引了依赖、写了SpringBootApplication注解项目就能跑起来的原因。SpringBootApplication本身是三个注解的组合SpringBootConfiguration声明是配置类、EnableAutoConfiguration开启自动配置、ComponentScan启动组件扫描。所以你在启动类里能直接扫描和注入自己的Bean。3.3 配置文件从XML山变成了清爽的key-valueSSM里用一堆XMLSpring Boot把配置收敛到一个文件里。同一个数据源配置SSM时期要写一个Bean定义加上一个properties文件还要手工引入Spring Boot里只需要这样spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/demo?serverTimezoneAsia/Shanghai username: root password: 123456 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity是不是非常直观每一行都是参数名值没有任何一对一的Bean配置。需要改连接、该SQL映射路径的时候改动成本非常低。配置文件本身成了项目里最简单的东西这也是Spring Boot普及后XML越来越少见的直接原因。4. SSM和Spring Boot的区别与联系一张表看懂如果你要让我用最精简的语言总结两者的关系我会用这个表对比维度SSMSpring Boot本质三个框架的组合方案一套快速开发框架脚手架底层基础基于Spring Framework同样基于Spring Framework配置方式大量XML properties注解 application.yml极少XML依赖管理手工管理版本手动对齐Starter起步依赖 版本统一管理Web服务器外置Tomcat打war包内嵌Tomcat打可执行jar启动方式部署到Tomcat后启动java -jar或mvn spring-boot:run与MyBatis关系手动配置 SqlSessionFactoryBean通过mybatis-spring-boot-starter自动装配学习门槛需要理解大量底层配置上手快但隐藏原理容易被忽略注意一点Spring Boot能做的事SSM基本都能做反过来SSM能做的事Spring Boot当然也都能做。因为Spring Boot从来没有丢弃SpringMVC和MyBatis它只是把它们从手工配置三件套变成了自动装配的一站式全家桶。从架构上看两者完全一致——请求来了走Controller → Service → Mapper → 数据库这一条链路在SSM和Spring Boot项目里没有任何区别。区别只在谁帮你把这些组件串起来、配起来这件事上SSM你得自己在XML里声明Bean和依赖Spring Boot在你引入starter和写配置后自动把这些事情办了。所以更准确地说Spring Boot不是SSM的替代品而是SSM配置方式的下一代产物。SpringMVC这个Web框架活得好好的只是你现在不用自己在XML里配置DispatcherServlet了MyBatis也活得好好的你只是不用再亲自声明SqlSessionFactoryBean了。5. 从SSM过渡到Spring Boot一次实际的代码迁移对照前面讲完理论这一节落地。我拿一个最典型的用户查询功能来对比——SSM里写长什么样Spring Boot里写长什么样。5.1 依赖层面的对照SSM的pom.xml你需要关心的核心依赖大概长这样properties spring.version5.0.8.RELEASE/spring.version mybatis.version3.4.6/mybatis.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version1.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.47/version /dependency !-- 还要有jackson、servlet-api、jsp-api等等... -- /dependenciesSpring Boot的pom.xml核心部分parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency /dependencies版本由父级统一锁定你不用再去逐个核对Spring和MyBatis的版本兼容性。哪个更省心不用我多说。5.2 代码层的对照业务代码本身几乎不动。Service、Mapper接口、Mapper映射XML在SSM和Spring Boot中写的内容完全一样。比如Mapper接口public interface UserMapper { User selectById(Param(id) Long id); }对应的XMLselect idselectById resultTypeUser select id, name, email from user where id #{id} /select这段代码无论你用的是SSM还是Spring Boot一个字母都不用改。SSM积累的MyBatis技能在Spring Boot项目中100%有效。Controller层也几乎一样。区别只在于SSM中的Controller类需要手动声明Controller注解并且要靠组件扫描注册而在Spring Boot下你的启动类已经开启了ComponentScanController和Service的注册方式完全一致RestController RequestMapping(/api/user) public class UserController { Autowired private UserService userService; GetMapping(/{id}) public ResultUser getUser(PathVariable Long id) { return Result.success(userService.selectById(id)); } }5.3 启动方式的对照这是最直观的区别。SSM项目要启动你得把项目打成war丢到Tomcat的webapps下面启动Tomcat访问路径还带着项目名然后等那些XML被加载完成。Spring Boot项目只需要mvn spring-boot:run或者打成jar之后java -jar demo-0.0.1-SNAPSHOT.jar启动日志里你能看到内嵌Tomcat在哪个端口启动自动配置装配了哪些Bean调试问题比以前方便得多。6. 面试和实际开发中该怎么理解两者的定位这个问题在Java后端面试里出现的频率非常高。我在面试候选人时一般不直接问SSM和Spring Boot的区别而是换着角度问比如既然Spring Boot这么好用SSM是不是没有存在价值了或者你了解自动配置的原理吗。这里我讲讲自己心中的标准理解框架。6.1 不要陷入谁取代谁的误区Spring Boot的出现并不意味着SSM已经过时。实际上大量成熟的老项目依然跑在SSM架构上这些项目需要维护SSM开发能力依然是有效的技能。Spring Boot的核心还是Spring FrameworkIoC容器、AOP、事务管理这些SSM阶段的核心能力在Boot项目里依然在底层发挥作用。如果你不懂Spring的IoC和AOP机制直接学Spring Boot遇到Bean加载不到、注入失效、事务不生效这种问题会很痛苦。很多Spring Boot我明明按教程配好了为什么报错的求助帖根源都在于底层原理没搞懂。所以正确的理解是SSM是一个历史阶段的技术方案Spring Boot是对这个方案的现代化升级两者共享同一套底层哲学。6.2 面试答题的结构如果有人问你这个问题我建议这样回答既体现你对历史的了解又体现你对原理的理解第一层先讲清楚这是两个不同层面的概念。SSM是Spring、SpringMVC、MyBatis三个框架的整合形式Spring Boot是Spring官方推出的快速开发脚手架。它们解决的是Web应用开发中从Web层到持久层的完整链路问题。第二层讲配置层面的差异。SSM需要大量XML手工装配Spring Boot通过starter和自动配置完成。举例说明比如DispatcherServlet和SqlSessionFactory在SSM里需要XML声明在Boot里通过spring.factories加载的自动配置类搞定。第三层讲两者的联系。Spring Boot没有淘汰SpringMVC和MyBatis是在它们之上做了封装。Boot项目中的Web开发依然是SpringMVC那一套处理机制Boot整合MyBatis依然走SqlSessionFactory和Mapper接口的路线。第四层如果对源码有了解可以讲讲SpringBootApplication、EnableAutoConfiguration、条件注解的判断过程。把这几层说清楚这道题基本稳了。7. 从SSM转向Spring Boot时我实际踩过的几个坑最后分享几个实操中常见的坑都是我当年自己踩过的。这些坑在纯Spring Boot教程里很难遇到但从SSM过渡过去的人会经常碰到。7.1 坑一事务不生效问题出在扫描与代理上我在SSM里事务是通过spring-config.xml里tx:annotation-driven/开启的配合数据源和事务管理器。到了Spring Boot我以为加上Transactional就行了结果好几个方法没走事务回滚。排查后发现原因有两个可能一是Service实现类里自己在同类中调用了另一个带有Transactional的方法方法间调用绕过了Spring生成的代理对象事务自然失效二是启动类扫描包的路径没覆盖到Service所在包导致Service的Bean根本没被Spring容器管理。解决方法是把启动类放在包的根路径确保ComponentScan扫描到所有需要管理的Bean并且把需要事务代理的调用拆到不同类中或者用Autowired注入自身代理。这个坑在SSM时期不容易遇到是因为XML配置里通常已经明确写了扫描哪些包很多人对容器管理哪些Bean是有感知的。到了Boot因为太自动了反而容易忽略包结构。7.2 坑二MyBatis的Mapper扫描漏配启动报错SSM里你会在spring-config.xml里配mybatis:scan base-packagecom.example.mapper/或者用MapperScan。到了Spring Boot初学者很容易忘记在启动类或者配置类上标注MapperScan结果启动时报找不到Mapper接口的Bean。两种解决方案一是在启动类上加MapperScan(com.example.mapper)二是在每个Mapper接口上直接加Mapper注解。我个人推荐第一种更集中、更好维护。这里的原理是MyBatis的starter只帮你装配了SqlSessionFactory但每个Mapper接口的代理对象生成需要明确告诉MyBatis扫描哪些包里的接口。7.3 坑三版本不匹配启动直接静默失败Spring Boot 2.7和3.x的差异很大比如javax.*包变成了jakarta.*很多老教程里的代码在Boot 3.x下跑不起来。如果你从SSM迁移时直接选了最新的Spring Boot版本而Mapper XML里用了老版本依赖的Driver类可能会出现数据源初始化失败但日志不明显的现象。建议从SSM过渡时先选用稳定的2.7.x版本这个版本与SSM时期的很多代码兼容度最高。等技术栈熟悉了再考虑升级到3.x升级时重点调整依赖坐标和带包名的导入类。7.4 坑四配置文件的差异不能只看表面对应从SSM的XML配置迁移到application.yml时很多人习惯性地逐行翻译。但有些配置在Boot里不是换了写法而是不再需要手工配置。比如在SSM里配置的InternalResourceViewResolver在Boot项目里如果你返回的是JSON根本不需要写只有你使用JSP模板时才需要额外加上视图解析器的配置。我见过有人把SSM的五六个XML文件里的Bean逐一搬到Boot的Configuration类里结果跟Boot的自动配置发生冲突两个相同的Bean加载出来后行为诡异。这个坑想提醒大家的是迁移配置首先要判断这个配置在Boot里是否已经被自动配置覆盖了而不是机械照搬。比如数据源、SqlSessionFactory、事务管理器Boot全部能自动装配你自己再定义一个反而可能造成冲突。最后再聊一点我的真实体会带过几年新人我发现一个挺普遍的现象从SSM学起的人虽然学的时候苦但对Spring的理解往往更扎实直接上手Spring Boot的人开发速度快但遇到问题容易抓瞎。这两种路径没有绝对的优劣但如果你现在还在学习阶段我的建议是两条路都走一遍——先用SSM搭一个最简单的小项目感受一下手写配置的繁琐和框架拼装的过程再切到Spring Boot体会自动配置给它带来的便利。这个过程走完你再回头看SSM与Spring Boot是什么关系这个问题会发现答案不是一个干巴巴的定义而是一条你自己走过的技术演进脉络。这个脉络比任何面试答案都值钱。