简介：面向Java Web开发者的SSM框架整合资源包，覆盖Spring、Spring MVC、MyBatis集成所需的主要jar依赖，帮助快速搭建项目基础环境，减少手动寻找、下载和导入第三方库的时间。压缩包共109个文件，以64个jar包为主体，配套14个XML配置模板、8个Java源码及8个class文件，另有properties配置文件、JSP页面等辅助内容，涵盖依赖库、Spring与MyBatis配置、DAO层映射及简单页面示例；整体为RAR格式，大小24.34MB，适合离线使用或迁移。该资源已有276人学习下载，适合正在学习三大框架整合、希望从零搭建SSM工程的初中级Java开发者。除完整依赖外，附带的XML、Java及class文件也能为DispatcherServlet配置、数据源设置、Mapper接口编写和事务管理提供直接参考，有利于排查配置错误、规避版本冲突，快速进入业务开发阶段。
1. 先搞清楚SSM整合到底需要哪些jar包，再动手下载
很多初学者在搭建SSM（Spring + Spring MVC + MyBatis）项目时，第一反应是去网上搜“ssm整合的所有jar包资源”，然后下载一个几十 MB 的压缩包，一股脑全塞进lib目录。结果项目启动时报错，根本分不清是缺包、包冲突还是版本不兼容。真正的问题在于，SSM 整合需要的不是某个单一 jar 文件，而是一组有依赖关系、有版本边界的 jar 包集合。
这一篇就顺着「SSM整合需要哪些jar包」这个题目，把依赖清单、版本选型、Maven 配置和手动下载两条路都讲清楚。适合三种人：刚接触 SSM 整合、想用 Maven 把依赖管起来的新手；还在用老式 lib 目录手动导包、经常被依赖冲突折腾的开发者；以及想系统梳理 SSM 各层 jar 包对应关系的熟手。先立住一个关键认知：jar 包从来不是越多越好，而是「够用 + 版本对齐」才算真的整合成功。
2. 从持久层到视图层：SSM整合的jar包全景清单与版本选型
SSM 整合的 jar 包按功能模块可以分成四组：Spring 核心与 Spring MVC、MyBatis 及 MyBatis-Spring 桥接包、数据库驱动与连接池、JSON 处理与日志组件。每组内部有版本关联，组与组之间靠 Spring 版本对外扩散。
2.1 Spring 与 Spring MVC 核心包
Spring 框架在 SSM 整合里至少需要六个核心模块：spring-core、spring-beans、spring-context、spring-web、spring-webmvc、spring-aop。其中spring-webmvc是 MVC 层的入口，它依赖spring-web，而spring-web依赖前面几个基础模块。如果你把这些包直接复制到 lib 目录，一个都不能少。
以 Spring 5.1.x 系列为例（这是我目前比较常用的基准版本），最小集合里的每个 jar 都有明确作用：
spring-core提供 IoC 容器的底层工具类，spring-beans负责 Bean 的创建与管理，spring-context是 ApplicationContext 的具体实现，spring-web提供 Web 上下文和DispatcherServlet需要的基础类，spring-webmvc则是 MVC 框架本体，spring-aop在整合事务管理和 MyBatis 拦截器时会被引用。
2.2 MyBatis 及与 Spring 桥接包
MyBatis 本体只需要两个 jar：mybatis-x.x.x.jar和它的依赖包。但 SSM 整合里真正容易漏的是mybatis-spring这个桥接包——它是 MyBatis 与 Spring 连接的关键，没有它，你无法在 Spring 容器里管理SqlSessionFactory和 Mapper 代理。
关于 MyBatis 版本与mybatis-spring版本的对应关系，建议在下载前先去 MyBatis 官方文档确认兼容矩阵。我的经验是：MyBatis 3.5.x 配mybatis-spring2.0.x，MyBatis 3.4.x 配mybatis-spring1.3.x，混用版本容易出现MapperScannerConfigurer初始化异常。
2.3 连接池、数据库驱动与 JSON 处理
数据库驱动 jar 必须与你的数据库版本严格对应。用 MySQL 的话，5.x 的 MySQL 用mysql-connector-java 5.1.x，MySQL 8.0+ 用mysql-connector-java 8.0.x，后者的驱动类名是com.mysql.cj.jdbc.Driver，URL 需要带serverTimezone参数，否则时间字段会读取报错。
连接池方面，推荐用druid或HikariCP。这两个池子都需要一个 jar 包，druid-spring-boot-starter只在 Spring Boot 场景下使用，SSM 手动整合用druid-x.x.x.jar即可。JSON 处理建议用jackson-databind，Spring MVC 的@ResponseBody返回 JSON 时默认依赖它，同时需要jackson-core和jackson-annotations，三个包版本要一致。
2.4 日志与 Web 容器相关包
SSM 项目一般用log4j或slf4j + logback组合。如果选slf4j + logback，需要slf4j-api、logback-core、logback-classic三个 jar。日志组件看似无关紧要，但spring-jcl（Spring 的日志桥接）如果和slf4j版本不匹配，启动时会输出满屏的告警，虽然不致命，却很影响排查问题。
下面这张表是我做 SSM 整合时常用的一组 jar 包清单，版本以稳定兼容为选择标准，没有刻意追新：
| 功能模块 | jar 包名称 | 推荐版本段 | 说明 |
|---|---|---|---|
| Spring 基础 | spring-core / spring-beans / spring-context | 5.1.x ~ 5.2.x | 版本需严格一致 |
| MVC | spring-web / spring-webmvc | 5.1.x ~ 5.2.x | 与 spring-context 同步 |
| AOP | spring-aop / aspectjweaver | 5.1.x ~ 5.2.x / 1.9.x | 事务注解需要 |
| MyBatis | mybatis | 3.5.x | 独立下载 |
| 桥接 | mybatis-spring | 2.0.x | 与 mybatis 3.5.x 匹配 |
| 数据库 | mysql-connector-java | 5.1.4x 或 8.0.x | 按 MySQL 版本选择 |
| 连接池 | druid | 1.2.x | 单 jar 包 |
| JSON | jackson-databind | 2.9.x ~ 2.12.x | 连带 core 和 annotations |
| 日志 | slf4j-api / logback | 1.7.x / 1.2.x | 三个 jar 一起用 |
提示：上面列的是「最常用稳定组合」，不代表「唯一正确组合」。版本选型的核心原则是：Spring 内部版本一致，MyBatis 与 mybatis-spring 按官方兼容表对，JDBC 驱动按数据库版本对。
3. 用Maven把jar包当依赖管起来：pom.xml配置与依赖树核查
说完 jar 包清单，接下来是实际落地。SSM 整合的 jar 包问题，用 Maven 管理是最省心的方式，因为 Maven 会自动拉取传递依赖，省去手工配对的麻烦。但 Maven 也不是没有坑：依赖冲突、scope 使用不当、本地仓库缓存旧包，都会让「原本应该能跑」的项目翻车。
3.1 一份可抄作业的 pom.xml 最小依赖配置
下面是一份基于 Spring 5.1.x + MyBatis 3.5.x 的 SSM 整合 pom.xml 核心片段，我用它起步过多个项目，可以作为参考模板。注意我把依赖分成了四段：Spring、MyBatis、数据库与连接池、Web 与 JSON。
<properties> <spring.version>5.1.9.RELEASE</spring.version> <mybatis.version>3.5.3</mybatis.version> </properties> <dependencies> <!-- Spring 核心与 MVC --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>${spring.version}</version> </dependency> <!-- MyBatis 与桥接包 --> <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.3</version> </dependency> <!-- 数据库驱动与连接池 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.47</version> <scope>runtime</scope> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.4</version> </dependency> <!-- Servlet 与 JSON --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.1.0</version> <scope>provided</scope> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.11.3</version> </dependency> </dependencies>这段配置里有几个值得注意的点：spring-jdbc是事务管理器DataSourceTransactionManager需要的，SSM 整合时容易漏；mysql-connector-java的 scope 设为runtime，因为编译期不需要直接引用驱动类；javax.servlet-api的 scope 设为provided，因为 Servlet 容器（Tomcat）自带这个 jar，打包时不应包含进去。
3.2 版本锁定与 scope 边界
Maven 项目的版本管理核心是「版本锁定」。上面的 pom.xml 用了properties统一 Spring 版本，这样可以保证spring-context和spring-webmvc不会出现一个 5.1.9 一个 5.2.0 的混搭状态。Spring 内部混版本是运行时最常见的问题，报错往往是深藏在AbstractApplicationContext里的NoSuchMethodError，极难排查。
scope 的边界也要注意：provided代表编译期可用、运行期由容器提供，runtime代表运行期需要、编译期不需要。用错 scope 会导致两种反向问题：把javax.servlet-api打成compile，部署到 Tomcat 时可能出现类冲突；把数据库驱动设为compile，虽然不影响运行，但打出来的 war 包会大一圈。
3.3 依赖树怎么看
pom.xml 写好后，执行mvn dependency:tree可以查看完整依赖树。这个命令在排查依赖冲突时是核心工具，它能把每个 jar 的来源层级打出来，方便定位「这个包到底是谁带进来的」。
mvn dependency:tree -Dincludes=org.springframework-Dincludes=org.springframework用来过滤指定组织的依赖，只看 Spring 相关的传递依赖树。如果发现同一个 artifact 出现了两个版本（比如spring-core既出现在 5.1.9 又出现在 5.2.0），就说明存在依赖冲突，需要在 pom 里用dependencyManagement锁定版本。
4. 不用Maven时的手动jar包路径：下载清单与lib目录部署
虽然不是主流，但确实有不少项目环境不允许用 Maven——比如内网服务器不能访问中央仓库，或者现有工程结构就是传统的 WebContent/WEB-INF/lib 模式。这时候「ssm整合的所有jar包资源」就成了字面意义上的手工活：下载 jar、按清单配对、放进 lib、验证。
4.1 从哪里下载 jar 包
手动下载 jar 的渠道一般是 Maven 中央仓库的 Web 界面，搜索 groupId 和 artifactId 就能找到对应版本的 jar 文件。下载时注意一个容易忽略的点：每个 jar 页面会有多个文件（jar、sources.jar、javadoc.jar），只需要下载不带后缀的主 jar 文件，不要下载 sources 和 javadoc，除非你想看源码。
4.2 lib 目录下的必选文件清单
按第 2 章的模块划分，手动模式下 lib 目录里至少要放齐这些文件：
lib/ ├── spring-core-5.1.9.RELEASE.jar ├── spring-beans-5.1.9.RELEASE.jar ├── spring-context-5.1.9.RELEASE.jar ├── spring-web-5.1.9.RELEASE.jar ├── spring-webmvc-5.1.9.RELEASE.jar ├── spring-aop-5.1.9.RELEASE.jar ├── spring-jdbc-5.1.9.RELEASE.jar ├── spring-expression-5.1.9.RELEASE.jar ├── mybatis-3.5.3.jar ├── mybatis-spring-2.0.3.jar ├── mysql-connector-java-5.1.47.jar ├── druid-1.2.4.jar ├── jackson-databind-2.11.3.jar ├── jackson-core-2.11.3.jar ├── jackson-annotations-2.11.3.jar ├── slf4j-api-1.7.30.jar ├── logback-core-1.2.3.jar ├── logback-classic-1.2.3.jar └── aspectjweaver-1.9.5.jar这份清单里比 Maven 模式多出了spring-expression和aspectjweaver：前者是 Spring EL 表达式的实现包，Spring 上下文初始化时实际需要；后者是 AspectJ 织入器，@Transactional注解的事务增强在运行期依赖它。手动模式下这两个包非常容易漏，漏掉后启动可能不报错，但事务注解会静默失效，这是相当隐蔽的问题。
4.3 部署时需要注意的包路径问题
手动模式下 jar 包放进WebContent/WEB-INF/lib后，还有两个细节决定项目能不能跑。一是不要同时把 jar 再复制一份到WEB-INF/classes下，Tomcat 加载类时会优先找WEB-INF/lib里的 jar，复制只会造成类加载顺序混乱。二是直接用 IntelliJ IDEA 部署时，确认 Artifacts 配置里选择了lib目录作为依赖来源，否则 ide 启动 Tomcat 时不会把 jar 打进 classpath。
5. SSM整合的jar包避坑：依赖冲突、缺包与运行期NoClassDefFoundError排查
这一章把我在 SSM 整合过程中反复遇到的 jar 包问题整理成几条踩坑记录，全部按「现象 → 原因 → 解决」的结构写，希望对后面接手的人有帮助。
5.1 现象：启动报 NoClassDefFoundError，但 IDEA 里看依赖并不缺包
有一次项目启动直接抛NoClassDefFoundError: org/springframework/jdbc/datasource/DataSourceTransactionManager。查看依赖列表，IDEA 里显示 spring-jdbc 是存在的，所以一开始很困惑。后来在mvn dependency:tree里发现问题：spring-jdbc被标记为<scope>provided</scope>，它被某条依赖传递进来时继承了这个 scope，导致运行期没有被包含进 war 包。
原因：scope 的传递性。某个依赖（比如 mybatis-spring）内部声明了provided的 spring-jdbc，传递到项目里后就变成了不可用状态。
解决：在项目 pom 里显式声明spring-jdbc依赖，不要依赖传递版本。这也是把 Spring 相关依赖全部显式声明的原因之一——避免传递依赖的 scope 污染。
5.2 现象：MyBatis 的 Mapper 扫描正常，但事务不生效
项目里配置了@Transactional，方法内故意抛异常后数据还是被提交了。日志里没报错，看起来一切正常。
原因：缺失aspectjweaver或spring-aop包。Spring 事务管理基于 AOP 代理，运行时需要 AspectJ 的织入能力。有些版本组合下缺少aspectjweaver不会立刻报错，因为代理是在第一次调用时才创建，失败信息被吞掉。
解决：手动模式下补上aspectjweaver和spring-aop两个 jar；Maven 模式下检查spring-context是否带了aop依赖，如果没有就在 pom 里显式加spring-aop和aspectjweaver。
5.3 现象：本地跑得好好的，部署到服务器后连接数据库失败
本地 IDEA 启动一切正常，放到服务器后 Tomcat 启动时抛出ClassNotFoundException: com.mysql.jdbc.Driver。
原因：MySQL 驱动被设为runtimescope，意味着编译期不需要，但运行期必须存在于 classpath。本地 IDE 因为缓存或 Artifacts 配置把驱动加进来了，服务器上打的 war 包里却没有这个 jar。
解决：确认打包时 war 内容的 classpath 里是否包含mysql-connector-java。手动模式下驱动 jar 必须放在WEB-INF/lib，不能放在 IDEA 的全局 library 里。
5.4 现象：明明下载了最新版 jar，启动还是报老版本特有的错误
有个项目引用了 Spring 5.2.x 的新特性，但运行时报NoSuchMethodError。明明下载时确认过 jar 包版本。
原因：本地 Maven 仓库缓存了旧版本。下载 jar 时如果 IDE 提示「已存在」，实际用的还是缓存里的旧文件。
解决：Maven 模式执行mvn -U强制更新快照版本；如果用的是固定的 release 版本，直接去本地仓库目录~/.m2/repository删掉对应 artifact 文件夹，再重新构建。
5.5 现象：日志打印了「SLF4J: Multiple bindings」告警
项目能启动，但控制台输出了很长一段 SLF4J 多绑定告警，看起来像报错，实际上只是 warning。
原因：classpath 里同时存在logback-classic和另一个 SLF4J 实现（比如slf4j-log4j12）。这些实现类都绑定到org.slf4j.impl.StaticLoggerBinder，SLF4J 随机选一个。
解决：检查依赖树，删除多余的绑定 jar。SSM 项目里常见的多余绑定源是某个依赖传递引入了slf4j-log4j12，在 pom 中用exclusion排除它。
6. 收尾：用dependency:tree做最终核对，把整合包袱变成常识
有了上面的清单和配置，SSM 整合最稳的验证手段不是「项目能启动」，而是「启动前先用依赖树把 jar 包状态看清楚」。
我现在的习惯是：每次做 SSM 整合，无论新建还是接手旧项目，都会先跑这两个命令：
mvn dependency:tree > deps.txt mvn dependency:tree -Dincludes=org.mybatis,com.alibaba > deps-check.txt第一个命令输出完整依赖树，用于核对 Spring 内部版本是否一致；第二个命令重点检查 MyBatis 和 Druid 连线，确认没有多版本残留。然后打开deps.txt搜索omitted for conflict，这行内容标注了哪两个 jar 存在冲突、谁被谁覆盖。这个动作只要花两分钟，却能省下启动时报错再回头排查的一两个小时。
如果你想验证「手动模式」下 lib 里的 jar 是否齐全，也有一个不用敲命令的笨办法：把 Tomcat 的webapps目录下的项目解压成文件夹，直接看WEB-INF/lib与第 4 章的清单逐项对照。这个方法虽然原始，但在没有 Maven 的环境里是最可靠的核对手段。
最后说一个我自己的血泪经验：SSM 整合的 jar 包问题，八成以上不是缺包，而是「多包」——多余的旧版本 jar 覆盖了新版本类，或多余的冲突实现污染了 classpath。所以遇到怪异的启动报错，先跑依赖树，再检查 lib 目录，最后才是换 jar 版本。按这个顺序排查，基本没有解决不了的 jar 包问题。希望帮到你。
本文还有配套的精品资源，点击获取
