SSM与Spring Boot是Java后端开发中经常被放在一起讨论的两套技术方案。许多开发者会把它们当作同一层面的框架进行对比，实际上这种理解并不准确。SSM是由Spring、Spring MVC和MyBatis三个独立框架组合而成的经典开发模式，侧重手动整合与细粒度控制；Spring Boot则是在Spring生态之上提供的一套快速构建工具，它并不替代Spring或MyBatis，而是通过自动配置、起步依赖和内嵌容器让开发者少写大量样板代码。理解二者的关系，有助于在项目启动阶段做出更合适的技术选型。
一、概念与定位：SSM是组合，Spring Boot是加速器
SSM中的Spring负责对象管理和事务控制，Spring MVC处理Web层的请求映射与视图解析，MyBatis承担数据持久化任务。三个框架各自独立，需要开发者在XML或Java配置类中手动声明数据源、事务管理器、Mapper扫描器、视图解析器等组件。一个典型的SSM项目通常包含web.xml、spring-mvc.xml、applicationContext.xml和mybatis-config.xml等多个配置文件。下面是一个简化版的web.xml配置片段：
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<servlet>
<servlet-name>dispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
</web-app>
仅DispatcherServlet的注册就需要声明servlet和servlet-mapping，再加上Spring上下文加载监听器、编码过滤器等内容，配置文件会迅速膨胀。Spring Boot改变了这种模式。它通过classpath中的依赖和条件注解，自动推断应用所需的Bean配置，并生成合理的默认值。开发者只需要提供一个启动类和少量application.yml配置即可运行项目。
二、核心差异逐项对比：配置、启动、部署与依赖管理
从配置复杂度看，SSM需要显式管理每个组件，Spring Boot则依据条件装配减少重复劳动。例如数据源配置，SSM要在applicationContext.xml中定义DataSource、SqlSessionFactory、MapperScannerConfigurer等多个Bean；Spring Boot只需在application.yml中写url、用户名和密码，其他交给自动配置。
server:
port: 8080
spring:
datasource:
url: jdbc:mysql://localhost:3306/demo?useSSL=false&serverTimezone=UTC
username: root
password: 123456
mybatis:
mapper-locations: classpath:mapper/*.xml
type-aliases-package: com.example.demo.entity
从启动方式看，SSM项目必须打包成war文件部署到外部Tomcat、Jetty等Servlet容器中；Spring Boot内置了Tomcat、Undertow或Jetty，可以直接运行带有main方法的Jar包。内嵌容器让本地开发和微服务部署更加轻量，也减少了环境差异带来的问题。
从依赖管理看，SSM项目常常需要手动核对Spring、MyBatis以及各类连接池的版本兼容性，升级一个组件可能引发连锁冲突。Spring Boot通过起步依赖和BOM统一管理版本，例如引入spring-boot-starter-web即可获得一组经过兼容性测试的Web相关依赖。下表总结了核心差异：
| 对比维度 | SSM | Spring Boot |
|---|---|---|
| 定位 | 框架组合 | 快速构建工具 |
| 配置方式 | 大量XML/Java配置 | 自动配置+少量属性 |
| 运行容器 | 外部Servlet容器 | 内嵌容器 |
| 打包形态 | war包 | 可执行jar或war |
| 依赖管理 | 手动协调版本 | 起步依赖和BOM |
| 微服务适配 | 需额外集成 | 天然支持Spring Cloud |
三、Spring Boot自动配置原理与常见问题
Spring Boot自动配置的核心是@EnableAutoConfiguration注解，它会根据classpath中存在的类、资源文件以及自定义Bean的情况，自动装配一组默认配置。例如检测到HikariCP在classpath中，就自动创建DataSource；发现spring-web依赖，就注册DispatcherServlet。可以通过启动类的@SpringBootApplication注解开启这一机制。
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class DemoApplication {
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
}
自动配置虽然方便，但也带来了学习和排查成本的增加。当项目出现奇怪的Bean冲突或配置未生效时，可以在application.yml中设置debug: true，然后在启动日志中查看Positive matches和Negative matches，了解哪些配置被应用或被跳过。另一个常见问题是自动配置的顺序与手动配置冲突：如果在项目中自己声明了一个同类Bean，自动配置通常会退让，但并非绝对，需要结合@ConditionalOnMissingBean等条件注解理解。
还需要注意MyBatis与Spring Boot的整合。引入mybatis-spring-boot-starter后，自动配置会扫描@Mapper注解的接口，无需再手动配置MapperScannerConfigurer。但如果同时保留了旧式XML配置，可能出现重复扫描或类型别名找不到的情况，建议在迁移时统一采用注解或统一使用XML映射文件。
四、SSM到Spring Boot的迁移与注意事项
从SSM迁移到Spring Boot并不是推倒重来。原有Service、Mapper、Controller代码基本可以保留，主要工作是移除web.xml、Spring配置文件和手动注册的Bean，然后引入起步依赖并调整配置文件。迁移顺序可以按层次推进：先迁移数据层，将MyBatis配置改为starter；再迁移Web层，删除DispatcherServlet相关配置；最后处理事务等横切配置。
迁移过程中常见问题包括：静态资源访问路径变化、拦截器注册方式从XML改为WebMvcConfigurer、以及配置文件优先级不同。Spring Boot默认加载application.yml或application.properties，属性可以通过命令行参数、环境变量等方式覆盖，优先级高于jar包内的配置。这为不同环境的部署提供了便利，但也要求团队明确配置来源，避免混乱。
五、总结与选型建议
SSM和Spring Boot并不是非此即彼的关系。Spring Boot本身就是基于Spring框架构建的，它默认集成的Web层依然是Spring MVC，数据层也常与MyBatis配合。因此团队在使用Spring Boot时，底层技术栈并没有改变，改变的是工程化方式和开发效率。
对于新启动的项目，如果团队已经熟悉Spring生态，建议直接使用Spring Boot，它能显著缩短搭建周期，并更容易向微服务架构演进。对于仍在维护的老旧SSM项目，不必强行重构，可以逐步引入Spring Boot的特性，或者在新模块中使用Spring Boot，通过多模块共存的方式平滑过渡。最终选型应结合项目规模、部署环境和团队经验综合决定。
Spring BootSSM框架区别修改时间：2026-08-30 01:27:41