尧图网站建设 
简介面向Java Web开发者的SSM整合依赖资源包用于快速搭建SpringSpring MVCMyBatis项目环境。压缩包共109个文件、24.34MB以64个jar包为主并包含14个XML配置、8个Java类与8个Class文件以及properties、JSP等辅助文件覆盖核心依赖库与基础配置示例。已有274人学习下载。包内还提供了DAO、Service、Controller分层的Java源码与编译后Class以及MyBatis映射、Spring/Spring MVC配置模板可用于参考依赖注入、事务管理和拦截器配置同时帮助核对不同组件的版本兼容性。对于准备整合SSM或排查依赖冲突的开发者可直接挑选对应jar包并参照配置迅速搭建工程节省逐个搜索与集成依赖库的时间。 刚学SSM的时候我干过一件蠢事从网上某个第三方资源站下了一个号称“最全SSM整合jar包合集”的压缩包解压出来一百多个jar包也分不清谁是谁直接全部塞进项目的WEB-INF/lib目录。结果Tomcat一启动先是ClassNotFoundException去掉几个再启动又变成NoSuchMethodError那一个晚上我基本就是在“启动→报错→搜索类名→再启动”的循环里度过的。后来踩了足够多的坑才想明白一件事SSM整合本身不难难的是jar包之间的依赖关系和版本匹配。Spring要管BeanSpringMVC要管请求分发MyBatis要管数据库访问这三层框架都有各自的一堆依赖包少一个容器就起不来版本配错三层中间就会出现各种诡异异常。这篇文章我就把一套能正常跑的SSM整合jar包资源彻底讲透每个jar包负责什么、版本怎么搭配、少一个会看到什么报错、部署之后又会踩哪些坑。打算做毕设、正在自学SSM、或者准备进公司接手老项目的同学应该都能用得上。1. 一套能启动的SSM第一步就是凑齐这三层依赖SSM不是一个大而全的框架而是Spring、SpringMVC、MyBatis三个框架的组合。每个框架都有自己的jar包体系整合的时候要确保三套东西在一套JVM环境里和平共处。先按层拆开看才知道每个jar包存在的意义。1.1 Spring容器层core、beans、context一个都不能少Spring是整个SSM的心脏负责对象创建、依赖注入、事务管理。它最基础的一组jar包是spring-coreSpring框架的基础工具类库几乎所有Spring模块都依赖它。spring-beansBean的创建和管理依赖注入的核心实现。spring-contextApplicationContext容器我们平时说的“Spring容器”主要就是这个包。spring-aopAOP代理实现SSM里声明式事务Transactional就是靠它才生效的。spring-expressionSpEL表达式SpringMVC参数绑定等场景会用到。很多教程会让你只引入spring-context以为它会自动把其他包带进来。这话在Maven里基本成立因为context会传递依赖core和beans但如果你是在手动往lib目录里塞jar包就非常容易漏掉spring-aop。漏掉它的后果很典型项目能启动Controller也能访问但Service上的Transactional完全不生效数据出了问题不回滚而且还没有任何报错。这类问题找起来极其痛苦因为它不是“不能运行”而是“运行结果不对”。1.2 SpringMVC层web、webmvc和Servlet相关包各管一段SpringMVC负责接收HTTP请求做参数绑定、模型渲染、JSON返回。这一层需要spring-web提供Web上下文、HttpServletRequest等web环境的基础支持。spring-webmvcDispatcherServlet和Controller、RequestMapping这些注解的核心实现。javax.servlet-apiServlet规范接口编译和运行时都需要它。jsp-api如果使用JSP作为视图层需要这个包。jstlJSP里使用c:forEach这类JSTL标签时的依赖。注意servlet-api和jsp-api在部署到Tomcat时要使用provided作用域因为Tomcat自带了这两个包。如果把它们打进WEB-INF/lib再部署会跟Tomcat自己的类产生冲突后面第5部分详细说。1.3 MyBatis层mybatis、mybatis-spring、驱动和连接池MyBatis负责数据持久化这一层需要的包相对少但每个都非常关键mybatisMyBatis核心框架SqlSession、MapperProxy这些基础机制都在里面。mybatis-spring这是SSM整合的“桥梁”。没有它在MyBatis的SqlSessionFactory就没法和Spring容器关联Mapper扫描注册也就无从谈起。数据库驱动比如mysql-connector-java连接MySQL必备。连接池Druid、C3P0、DBCP2至少选一个。一个很容易被忽略的点如果选C3P0光引入c3p0一个jar包还不够它还需要依赖mchange-commons-java。很多手动收集jar包的人漏掉这个依赖运行时报类找不到跟c3p0本身没关系。Druid则是个单包用起来省心一些这也是我在实际项目里更倾向Druid的原因。1.4 容易被忽略的隐形依赖JSON、日志和单元测试这类包在项目启动时不一定会触发但跑到某个功能时就跳出来了所以我把它们归为“隐形包”。jackson-databindController方法上写ResponseBody返回JSON对象时SpringMVC需要Jackson来完成对象到JSON的序列化。没有它访问接口直接报415或HttpMediaTypeNotAcceptableException。slf4j-api logback-classicSpring和MyBatis的日志输出都走SLF4J接口。只引入了接口而没有实现控制台会一片安静MyBatis执行的SQL也看不到。spring-test junit如果只是想快速验证某个Mapper能不能查通写个单元测试比启动整个Web工程省事得多。2. 版本搭配才是最大的坑我实测过两组稳定组合jar包不是堆在一起就能用版本错配带来的问题比缺包还难查。缺包至少会报ClassNotFoundException一眼就能看到版本不匹配是NoSuchMethodError提示的类与方法名常常让你怀疑自己写的代码是不是有问题。2.1 Spring 4.3时代最经典的老项目组合如果你的开发环境是JDK 8并且准备接手或复现一个老SSM工程这套组合是被验证过无数次的Spring Framework 4.3.20.RELEASEMyBatis 3.4.6mybatis-spring 1.3.2mysql-connector-java 5.1.47Druid 1.1.21Jackson 2.9.10slf4j 1.7.25 logback 1.2.3javax.servlet-api 3.1.0这套组合最稳的原因在于mybatis-spring 1.3.x是针对Spring 4.x时代设计的两者配合多年基本没有兼容性裂缝。MyBatis 3.4.6也是3.4系列里比较稳定的版本。2.2 Spring 5时代新项目更建议的版本组合如果你是新项目环境是JDK 8以上我建议直接上Spring 5Spring Framework 5.1.20.RELEASE 或 5.2.xMyBatis 3.5.x比如3.5.15mybatis-spring 2.0.7mysql-connector-java 8.0.xDruid 1.1.24Jackson 2.11.x 或更高这里有个硬性匹配规则mybatis-spring 2.0.x要求Spring 5.0以上绝对不能拿它配Spring 4.3反过来mybatis-spring 1.3.x配Spring 5也能用但没必要在旧版本上纠结。还有一点MySQL 8以上如果还用mysql-connector-java 5.1.x驱动类名要写com.mysql.jdbc.Driver8.0.x则要写com.mysql.cj.jdbc.Driver还要显式加上时区参数serverTimezone。这一点经常让老项目迁移数据库时栽跟头。2.3 版本不匹配时常见的报错长相java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton一般是Spring各模块版本不一致比如spring-beans是4.x、spring-context却装个5.x。java.lang.NoClassDefFoundError: org/mybatis/spring/SqlSessionFactoryBeanMyBatis核心和mybatis-spring版本跨度太大。java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory服务器JDK版本和XML解析库冲突常见于老项目跑在新JDK上。3. 直接抄作业完整Maven依赖配置与手动lib目录思路如果还在用eclipse或idea把jar包一个个往项目里塞我建议尽量改成Maven或Gradle。Maven的意义不只是自动下载更重要的是帮你管理传递依赖。一条mvn dependency:tree命令就能把整棵依赖树摊开缺什么、谁带谁一目了然。3.1 pom.xml核心依赖段下面这段配置以Spring 5组合为例是实测可用的properties spring.version5.1.20.RELEASE/spring.version mybatis.version3.5.15/mybatis.version mybatis.spring.version2.0.7/mybatis.spring.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version${spring.version}/version /dependency !-- SpringMVC -- dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency !-- 事务与JDBC -- dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version${spring.version}/version /dependency !-- MyBatis -- dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version${mybatis.spring.version}/version /dependency !-- MySQL驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version scoperuntime/scope /dependency !-- Druid连接池 -- dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.1.24/version /dependency !-- JSON -- dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.11.4/version /dependency !-- Servlet API -- dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version3.1.0/version scopeprovided/scope /dependency !-- JSTL -- dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId version1.2/version /dependency /dependencies我没有把spring-aspects单独列出来因为SSM里的事务管理主要用Transactional注解它不是基于AspectJ切面而是Spring自身的动态代理。但spring-context会自动带上spring-aop相关依赖这一点通过依赖树可以看到。如果你确实要写Aspect注解的切面才需要单独加spring-aspects。3.2 手动收集lib目录的做法有些环境确实不让你用Maven比如公司内网、老式集成开发环境或者领导指定必须用原始方式部署那就只能在WEB-INF/lib下面手工放jar包。我的建议是把收藏的jar包按功能分目录保存别让一百多个jar包挤在一层目录里。整理规则可以是spring-all目录所有org.springframework命名的jar包mybatis目录mybatis和mybatis-springdatabase目录驱动和连接池other目录Jackson、日志、commons系列另外最好给每个jar包备注版本号。我见过太多人把spring-core-4.3.20.RELEASE.jar简写成spring-core.jar后来升级版本时直接分不清谁是谁。命名时带着完整版本号能少很多麻烦。3.3 用dependency:tree检查依赖冲突Maven工程里最常用的排查命令mvn dependency:tree -Dverbose如果某几个包版本冲突会输出omitted for conflict之类的提示。看到这种字样优先保留版本号高的那个除非高版本确认有兼容性问题。4. 缺jar包时最常见的四类报错与定位方法SSM整合阶段的报错其实很有规律。我总结了一套排查思路先看异常栈最顶部的Caused by然后抓缺失的类全限定名再反查它属于哪个jar包。记住永远不要在一百多个jar包里用肉眼找要用工具。4.1 ClassNotFoundException直接看缺失类名判断是哪个包比如报错Caused by: java.lang.ClassNotFoundException: org.springframework.context.support.AbstractApplicationContext很明显是spring-context没引入。Method org.apache.ibatis.session.SqlSessionFactoryBuilder说明mybatis核心包缺失。Method org.mybatis.spring.SqlSessionFactoryBean说明mybatis-spring缺失。这里有个小技巧IDEA里双击Shift直接输入类名如果能在External Libraries里搜到说明类在依赖里存在搜不到就一定是缺某个包。在命令行环境可以用jar tf命令反查jar tf mybatis-spring-2.0.7.jar | grep SqlSessionFactoryBean4.2 NoSuchMethodError先怀疑版本冲突这种错误比ClassNotFoundException狠因为类存在但方法签名变了。最常见的场景是一个老版本的jar包和一个新版本的jar包同时出现在classpath里类加载器加载了旧版本代码调用了新版本的方法。解决办法是统一版本号用Maven的dependencyManagement锁定版本或者手动把lib下同名的不同版本jar包清理掉。4.3 控制台完全没有SQL日志slf4j绑定问题SSM项目启动正常、请求正常、数据也返回了但控制台看不到MyBatis打印的SQL这种时候八成是slf4j-api有了但缺少logback或log4j绑定实现。Spring Boot项目通常自带日志SSM这种手拼工程不会要手动加slf4j-api和logback-classic两个包并确认没有同时引入多个绑定比如一个工程里slf4j-log4j12和logback-classic同时存在就会出现绑定冲突。4.4 MapperFactoryBean找不到mybatis-spring没加进来Spring启动时报org.apache.ibatis.binding.MapperFactoryBean找不到十有八九是mybatis-spring没引入。另一种可能是我上面提过的版本跨度问题MyBatis 3.2配了mybatis-spring 2.0.7报错会从类或方法签名层面表现出奇奇怪怪的症状。这时候别死磕版本直接把配置改成上面那组验证过的组合再试。5. 部署到Tomcat后ClassNotFoundscope和lib重复是两个大坑本地IDEA跑得好好的一打war包丢到Tomcat就报ClassNotFoundException这类问题在SSM整合中太常见了。核心原因大多数集中在scope设置错误和WEB-INF/lib下有重复jar包。5.1 provided和runtime到底有什么区别provided表示“编译时需要运行时不打包”。servlet-api、jsp-api就是典型本地编译时用它们运行时由Tomcat提供。如果把它们打成war包放进lib目录本地Tomcat可能睁一只眼闭一只眼线上Tomcat则可能出现NoSuchMethodError因为同一个类被加载了两份。runtime表示“编译时不需要运行时才需要”。mysql驱动就是典型例子编译时没有它也能过运行时才加载所以配成runtime可以减少编译期的依赖噪音。5.2 WEB-INF/lib下重复jar包手动往lib目录塞包时最常见的低级错误是把spring-core同时放了4.3和5.2两个版本。classloader在加载时会按顺序解析很容易命中低版本。排查时先用命令数一下重复包find WEB-INF/lib -name *.jar | xargs -n1 basename | sort | uniq -d看到重复的全部清理成统一版本。5.3 Tomcat版本和javax.servlet版本对应关系不同版本的Tomcat内置Servlet版本不同Tomcat 7Servlet 3.0Tomcat 8 / 8.5Servlet 3.1Tomcat 9Servlet 4.0如果本地编译用的是javax.servlet-api 4.0部署到Tomcat 8.5上某些新API调用就会在运行时NoSuchMethodError。老SSM工程通常javax.servlet-api 3.1.0配Tomcat 8.5最稳。6. 用最小工程验证这套jar包组合靠不靠谱最后分享一套我自己的验证方法。每次搭SSM环境我不会一上来就写几十个类而是先做一个最小闭环请求进来、Spring容器接管、MyBatis查库、JSON返回。这个闭环全通了才说明jar包层面的问题清零了。6.1 最小工程结构只需要这些文件web.xml配置ContextLoaderListener和DispatcherServletapplicationContext.xmlSpring容器配置扫描Service和Mapperspring-mvc.xmlSpringMVC配置扫描Controller开启注解驱动一个Controller方法返回“ok”字符串一个Mapper接口和一个简单查询语句6.2 三步验证法第一步启动Tomcat看控制台是否打印Spring容器初始化日志以及“Tomcat started on port(s): 8080”之类提示。没有Error就是容器层没问题。第二步访问一个返回纯字符串的Controller比如/hello。能返回说明SpringMVC的DispatcherServlet、HandlerMapping、视图解析这一整套链路正常。再加一个返回Map对象的方法如果JSON正常输出说明Jackson没问题。第三步调一个带Mapper查询的接口。这一步把MyBatis、数据库驱动、连接池全部串起来了。重点看控制台有没有打印SQL日志如果SQL出来了数据和日志都正常这套jar包组合就可以放心用了。6.3 一点额外建议这套验证方法也可以反过来用项目出了问题先把业务代码注释掉只跑这最小闭环看是jar包问题还是自己的代码问题。我调试SSM项目依赖问题时经常用这个办法缩小范围比在几百行业务代码里找原因快得多。关于SSM整合jar包这块我个人体会最深的一点是千万别迷信网上打包好的“jar包全家桶”。这类资源大多版本混乱来源不明还要冒着引入恶意代码的风险。其实jar包从来都不是靠“收集”得来的而是靠明确的依赖管理生成的。把本文的Maven配置保存一份以后不管是新建项目还是排查问题照着这套稳定版本来基本不会在依赖上浪费太多时间。真遇到老项目里的特殊包找不到了去Maven中央仓库按groupId和artifactId精确下载比在任何第三方合集里大海捞针都靠谱。本文还有配套的精品资源点击获取 SSM整合jar包依赖全解析：版本搭配与排错实战
简介面向Java Web开发者的SSM整合依赖资源包用于快速搭建SpringSpring MVCMyBatis项目环境。压缩包共109个文件、24.34MB以64个jar包为主并包含14个XML配置、8个Java类与8个Class文件以及properties、JSP等辅助文件覆盖核心依赖库与基础配置示例。已有274人学习下载。包内还提供了DAO、Service、Controller分层的Java源码与编译后Class以及MyBatis映射、Spring/Spring MVC配置模板可用于参考依赖注入、事务管理和拦截器配置同时帮助核对不同组件的版本兼容性。对于准备整合SSM或排查依赖冲突的开发者可直接挑选对应jar包并参照配置迅速搭建工程节省逐个搜索与集成依赖库的时间。 刚学SSM的时候我干过一件蠢事从网上某个第三方资源站下了一个号称“最全SSM整合jar包合集”的压缩包解压出来一百多个jar包也分不清谁是谁直接全部塞进项目的WEB-INF/lib目录。结果Tomcat一启动先是ClassNotFoundException去掉几个再启动又变成NoSuchMethodError那一个晚上我基本就是在“启动→报错→搜索类名→再启动”的循环里度过的。后来踩了足够多的坑才想明白一件事SSM整合本身不难难的是jar包之间的依赖关系和版本匹配。Spring要管BeanSpringMVC要管请求分发MyBatis要管数据库访问这三层框架都有各自的一堆依赖包少一个容器就起不来版本配错三层中间就会出现各种诡异异常。这篇文章我就把一套能正常跑的SSM整合jar包资源彻底讲透每个jar包负责什么、版本怎么搭配、少一个会看到什么报错、部署之后又会踩哪些坑。打算做毕设、正在自学SSM、或者准备进公司接手老项目的同学应该都能用得上。1. 一套能启动的SSM第一步就是凑齐这三层依赖SSM不是一个大而全的框架而是Spring、SpringMVC、MyBatis三个框架的组合。每个框架都有自己的jar包体系整合的时候要确保三套东西在一套JVM环境里和平共处。先按层拆开看才知道每个jar包存在的意义。1.1 Spring容器层core、beans、context一个都不能少Spring是整个SSM的心脏负责对象创建、依赖注入、事务管理。它最基础的一组jar包是spring-coreSpring框架的基础工具类库几乎所有Spring模块都依赖它。spring-beansBean的创建和管理依赖注入的核心实现。spring-contextApplicationContext容器我们平时说的“Spring容器”主要就是这个包。spring-aopAOP代理实现SSM里声明式事务Transactional就是靠它才生效的。spring-expressionSpEL表达式SpringMVC参数绑定等场景会用到。很多教程会让你只引入spring-context以为它会自动把其他包带进来。这话在Maven里基本成立因为context会传递依赖core和beans但如果你是在手动往lib目录里塞jar包就非常容易漏掉spring-aop。漏掉它的后果很典型项目能启动Controller也能访问但Service上的Transactional完全不生效数据出了问题不回滚而且还没有任何报错。这类问题找起来极其痛苦因为它不是“不能运行”而是“运行结果不对”。1.2 SpringMVC层web、webmvc和Servlet相关包各管一段SpringMVC负责接收HTTP请求做参数绑定、模型渲染、JSON返回。这一层需要spring-web提供Web上下文、HttpServletRequest等web环境的基础支持。spring-webmvcDispatcherServlet和Controller、RequestMapping这些注解的核心实现。javax.servlet-apiServlet规范接口编译和运行时都需要它。jsp-api如果使用JSP作为视图层需要这个包。jstlJSP里使用c:forEach这类JSTL标签时的依赖。注意servlet-api和jsp-api在部署到Tomcat时要使用provided作用域因为Tomcat自带了这两个包。如果把它们打进WEB-INF/lib再部署会跟Tomcat自己的类产生冲突后面第5部分详细说。1.3 MyBatis层mybatis、mybatis-spring、驱动和连接池MyBatis负责数据持久化这一层需要的包相对少但每个都非常关键mybatisMyBatis核心框架SqlSession、MapperProxy这些基础机制都在里面。mybatis-spring这是SSM整合的“桥梁”。没有它在MyBatis的SqlSessionFactory就没法和Spring容器关联Mapper扫描注册也就无从谈起。数据库驱动比如mysql-connector-java连接MySQL必备。连接池Druid、C3P0、DBCP2至少选一个。一个很容易被忽略的点如果选C3P0光引入c3p0一个jar包还不够它还需要依赖mchange-commons-java。很多手动收集jar包的人漏掉这个依赖运行时报类找不到跟c3p0本身没关系。Druid则是个单包用起来省心一些这也是我在实际项目里更倾向Druid的原因。1.4 容易被忽略的隐形依赖JSON、日志和单元测试这类包在项目启动时不一定会触发但跑到某个功能时就跳出来了所以我把它们归为“隐形包”。jackson-databindController方法上写ResponseBody返回JSON对象时SpringMVC需要Jackson来完成对象到JSON的序列化。没有它访问接口直接报415或HttpMediaTypeNotAcceptableException。slf4j-api logback-classicSpring和MyBatis的日志输出都走SLF4J接口。只引入了接口而没有实现控制台会一片安静MyBatis执行的SQL也看不到。spring-test junit如果只是想快速验证某个Mapper能不能查通写个单元测试比启动整个Web工程省事得多。2. 版本搭配才是最大的坑我实测过两组稳定组合jar包不是堆在一起就能用版本错配带来的问题比缺包还难查。缺包至少会报ClassNotFoundException一眼就能看到版本不匹配是NoSuchMethodError提示的类与方法名常常让你怀疑自己写的代码是不是有问题。2.1 Spring 4.3时代最经典的老项目组合如果你的开发环境是JDK 8并且准备接手或复现一个老SSM工程这套组合是被验证过无数次的Spring Framework 4.3.20.RELEASEMyBatis 3.4.6mybatis-spring 1.3.2mysql-connector-java 5.1.47Druid 1.1.21Jackson 2.9.10slf4j 1.7.25 logback 1.2.3javax.servlet-api 3.1.0这套组合最稳的原因在于mybatis-spring 1.3.x是针对Spring 4.x时代设计的两者配合多年基本没有兼容性裂缝。MyBatis 3.4.6也是3.4系列里比较稳定的版本。2.2 Spring 5时代新项目更建议的版本组合如果你是新项目环境是JDK 8以上我建议直接上Spring 5Spring Framework 5.1.20.RELEASE 或 5.2.xMyBatis 3.5.x比如3.5.15mybatis-spring 2.0.7mysql-connector-java 8.0.xDruid 1.1.24Jackson 2.11.x 或更高这里有个硬性匹配规则mybatis-spring 2.0.x要求Spring 5.0以上绝对不能拿它配Spring 4.3反过来mybatis-spring 1.3.x配Spring 5也能用但没必要在旧版本上纠结。还有一点MySQL 8以上如果还用mysql-connector-java 5.1.x驱动类名要写com.mysql.jdbc.Driver8.0.x则要写com.mysql.cj.jdbc.Driver还要显式加上时区参数serverTimezone。这一点经常让老项目迁移数据库时栽跟头。2.3 版本不匹配时常见的报错长相java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton一般是Spring各模块版本不一致比如spring-beans是4.x、spring-context却装个5.x。java.lang.NoClassDefFoundError: org/mybatis/spring/SqlSessionFactoryBeanMyBatis核心和mybatis-spring版本跨度太大。java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory服务器JDK版本和XML解析库冲突常见于老项目跑在新JDK上。3. 直接抄作业完整Maven依赖配置与手动lib目录思路如果还在用eclipse或idea把jar包一个个往项目里塞我建议尽量改成Maven或Gradle。Maven的意义不只是自动下载更重要的是帮你管理传递依赖。一条mvn dependency:tree命令就能把整棵依赖树摊开缺什么、谁带谁一目了然。3.1 pom.xml核心依赖段下面这段配置以Spring 5组合为例是实测可用的properties spring.version5.1.20.RELEASE/spring.version mybatis.version3.5.15/mybatis.version mybatis.spring.version2.0.7/mybatis.spring.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version${spring.version}/version /dependency !-- SpringMVC -- dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency !-- 事务与JDBC -- dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version${spring.version}/version /dependency !-- MyBatis -- dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version${mybatis.spring.version}/version /dependency !-- MySQL驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version scoperuntime/scope /dependency !-- Druid连接池 -- dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.1.24/version /dependency !-- JSON -- dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.11.4/version /dependency !-- Servlet API -- dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version3.1.0/version scopeprovided/scope /dependency !-- JSTL -- dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId version1.2/version /dependency /dependencies我没有把spring-aspects单独列出来因为SSM里的事务管理主要用Transactional注解它不是基于AspectJ切面而是Spring自身的动态代理。但spring-context会自动带上spring-aop相关依赖这一点通过依赖树可以看到。如果你确实要写Aspect注解的切面才需要单独加spring-aspects。3.2 手动收集lib目录的做法有些环境确实不让你用Maven比如公司内网、老式集成开发环境或者领导指定必须用原始方式部署那就只能在WEB-INF/lib下面手工放jar包。我的建议是把收藏的jar包按功能分目录保存别让一百多个jar包挤在一层目录里。整理规则可以是spring-all目录所有org.springframework命名的jar包mybatis目录mybatis和mybatis-springdatabase目录驱动和连接池other目录Jackson、日志、commons系列另外最好给每个jar包备注版本号。我见过太多人把spring-core-4.3.20.RELEASE.jar简写成spring-core.jar后来升级版本时直接分不清谁是谁。命名时带着完整版本号能少很多麻烦。3.3 用dependency:tree检查依赖冲突Maven工程里最常用的排查命令mvn dependency:tree -Dverbose如果某几个包版本冲突会输出omitted for conflict之类的提示。看到这种字样优先保留版本号高的那个除非高版本确认有兼容性问题。4. 缺jar包时最常见的四类报错与定位方法SSM整合阶段的报错其实很有规律。我总结了一套排查思路先看异常栈最顶部的Caused by然后抓缺失的类全限定名再反查它属于哪个jar包。记住永远不要在一百多个jar包里用肉眼找要用工具。4.1 ClassNotFoundException直接看缺失类名判断是哪个包比如报错Caused by: java.lang.ClassNotFoundException: org.springframework.context.support.AbstractApplicationContext很明显是spring-context没引入。Method org.apache.ibatis.session.SqlSessionFactoryBuilder说明mybatis核心包缺失。Method org.mybatis.spring.SqlSessionFactoryBean说明mybatis-spring缺失。这里有个小技巧IDEA里双击Shift直接输入类名如果能在External Libraries里搜到说明类在依赖里存在搜不到就一定是缺某个包。在命令行环境可以用jar tf命令反查jar tf mybatis-spring-2.0.7.jar | grep SqlSessionFactoryBean4.2 NoSuchMethodError先怀疑版本冲突这种错误比ClassNotFoundException狠因为类存在但方法签名变了。最常见的场景是一个老版本的jar包和一个新版本的jar包同时出现在classpath里类加载器加载了旧版本代码调用了新版本的方法。解决办法是统一版本号用Maven的dependencyManagement锁定版本或者手动把lib下同名的不同版本jar包清理掉。4.3 控制台完全没有SQL日志slf4j绑定问题SSM项目启动正常、请求正常、数据也返回了但控制台看不到MyBatis打印的SQL这种时候八成是slf4j-api有了但缺少logback或log4j绑定实现。Spring Boot项目通常自带日志SSM这种手拼工程不会要手动加slf4j-api和logback-classic两个包并确认没有同时引入多个绑定比如一个工程里slf4j-log4j12和logback-classic同时存在就会出现绑定冲突。4.4 MapperFactoryBean找不到mybatis-spring没加进来Spring启动时报org.apache.ibatis.binding.MapperFactoryBean找不到十有八九是mybatis-spring没引入。另一种可能是我上面提过的版本跨度问题MyBatis 3.2配了mybatis-spring 2.0.7报错会从类或方法签名层面表现出奇奇怪怪的症状。这时候别死磕版本直接把配置改成上面那组验证过的组合再试。5. 部署到Tomcat后ClassNotFoundscope和lib重复是两个大坑本地IDEA跑得好好的一打war包丢到Tomcat就报ClassNotFoundException这类问题在SSM整合中太常见了。核心原因大多数集中在scope设置错误和WEB-INF/lib下有重复jar包。5.1 provided和runtime到底有什么区别provided表示“编译时需要运行时不打包”。servlet-api、jsp-api就是典型本地编译时用它们运行时由Tomcat提供。如果把它们打成war包放进lib目录本地Tomcat可能睁一只眼闭一只眼线上Tomcat则可能出现NoSuchMethodError因为同一个类被加载了两份。runtime表示“编译时不需要运行时才需要”。mysql驱动就是典型例子编译时没有它也能过运行时才加载所以配成runtime可以减少编译期的依赖噪音。5.2 WEB-INF/lib下重复jar包手动往lib目录塞包时最常见的低级错误是把spring-core同时放了4.3和5.2两个版本。classloader在加载时会按顺序解析很容易命中低版本。排查时先用命令数一下重复包find WEB-INF/lib -name *.jar | xargs -n1 basename | sort | uniq -d看到重复的全部清理成统一版本。5.3 Tomcat版本和javax.servlet版本对应关系不同版本的Tomcat内置Servlet版本不同Tomcat 7Servlet 3.0Tomcat 8 / 8.5Servlet 3.1Tomcat 9Servlet 4.0如果本地编译用的是javax.servlet-api 4.0部署到Tomcat 8.5上某些新API调用就会在运行时NoSuchMethodError。老SSM工程通常javax.servlet-api 3.1.0配Tomcat 8.5最稳。6. 用最小工程验证这套jar包组合靠不靠谱最后分享一套我自己的验证方法。每次搭SSM环境我不会一上来就写几十个类而是先做一个最小闭环请求进来、Spring容器接管、MyBatis查库、JSON返回。这个闭环全通了才说明jar包层面的问题清零了。6.1 最小工程结构只需要这些文件web.xml配置ContextLoaderListener和DispatcherServletapplicationContext.xmlSpring容器配置扫描Service和Mapperspring-mvc.xmlSpringMVC配置扫描Controller开启注解驱动一个Controller方法返回“ok”字符串一个Mapper接口和一个简单查询语句6.2 三步验证法第一步启动Tomcat看控制台是否打印Spring容器初始化日志以及“Tomcat started on port(s): 8080”之类提示。没有Error就是容器层没问题。第二步访问一个返回纯字符串的Controller比如/hello。能返回说明SpringMVC的DispatcherServlet、HandlerMapping、视图解析这一整套链路正常。再加一个返回Map对象的方法如果JSON正常输出说明Jackson没问题。第三步调一个带Mapper查询的接口。这一步把MyBatis、数据库驱动、连接池全部串起来了。重点看控制台有没有打印SQL日志如果SQL出来了数据和日志都正常这套jar包组合就可以放心用了。6.3 一点额外建议这套验证方法也可以反过来用项目出了问题先把业务代码注释掉只跑这最小闭环看是jar包问题还是自己的代码问题。我调试SSM项目依赖问题时经常用这个办法缩小范围比在几百行业务代码里找原因快得多。关于SSM整合jar包这块我个人体会最深的一点是千万别迷信网上打包好的“jar包全家桶”。这类资源大多版本混乱来源不明还要冒着引入恶意代码的风险。其实jar包从来都不是靠“收集”得来的而是靠明确的依赖管理生成的。把本文的Maven配置保存一份以后不管是新建项目还是排查问题照着这套稳定版本来基本不会在依赖上浪费太多时间。真遇到老项目里的特殊包找不到了去Maven中央仓库按groupId和artifactId精确下载比在任何第三方合集里大海捞针都靠谱。本文还有配套的精品资源点击获取