SSM风俗文化管理系统：从解压到跑通全流程避坑指南

简介：该毕业设计源码实现了一套基于Spring、SpringMVC、MyBatis框架整合开发的风俗文化管理系统。后端采用Java语言编写，前端使用JSP页面技术，数据存储选用MySQL数据库，整体采用浏览器与服务器结构的B/S架构模式。系统设计了系统管理员与普通用户两个角色，管理员登录后台后可以管理用户信息、节日风俗、饮食风俗、服饰风俗、礼仪风俗、信仰风俗、建筑风俗、我的收藏、留言板、论坛以及系统设置等模块；普通用户则可以浏览各类风俗文化资讯、收藏感兴趣的内容、发布留言参与论坛互动。功能设计完整地覆盖了从后台信息维护、前台内容展示到用户交互反馈的整个管理流程。该工程以ZIP压缩包形式提供，大小约26MB，内含完整项目源码，能清晰体现SSM框架的分层结构、JSP视图层与MySQL数据表之间的关联，适合作为毕业设计或课程设计的基础。对于需要学习SSM整合开发、理解信息管理系统通用模块的Java初学者和高校学生，这份源码能够提供直观的代码参考与业务设计思路。目前已有106人浏览学习，值得作为同类项目的实践范本。

1. 基于 SSM 的风俗文化管理系统.zip：解压之前先弄清楚包里是什么

收到「基于 ssm 的风俗文化管理系统.zip」这种文件，大概率是三种情况：课程设计作业、毕业设计源码、或者从同事手里接过来的二手项目。解压之后你通常会看到一套老熟人组合——Spring、Spring MVC、MyBatis 堆在一起，没有 Spring Boot 的自动配置，前端是 JSP 配 jQuery，数据库是 MySQL，中间还夹着大量注解和 XML。这套系统能办的事很实在：前台展示风俗文化条目，后台做登录、分类管理、条目增删改查、图片上传这些典型业务。它适合拿来交课设、改毕设、或者作为 SSM 教学范例逐层拆开看。这篇笔记按我接手这类 zip 的习惯来写，从拆目录讲起，落到跑通流程、认注解、排坑，最后说怎么验收它值不值得继续投入。

2. 先拆项目骨架：SSM 三个框架在风俗系统里各管哪一块

2.1 怎么判断一个 zip 是不是标准 SSM 项目

解开 zip 先别急着用 IDEA 打开，先用文件管理器看根目录。是不是 Maven 项目，最明显的标记是根目录有没有pom.xml。SSM 的 Maven 项目里，pom 文件必然有spring-webmvc、mybatis、mybatis-spring这三个依赖，缺了任一个都谈不上标准 SSM。如果没有 pom.xml，就去看WEB-INF/lib下面有没有 spring-web 和 mybatis 的 jar 包，这是手工导包的老式工程，后面我讲的 Maven 命令在它身上不适用。

然后看配置文件。标准的 SSM 至少有这几件套：web.xml（放在 WEB-INF 下，注册 DispatcherServlet 和 ContextLoaderListener）、spring-mvc.xml（负责 Controller 层）、applicationContext.xml（负责 Service、Mapper、事务）、jdbc.properties（数据库连接参数），以及可选的mybatis-config.xml。我的判断习惯是：看到 web.xml 里配了 DispatcherServlet，且 init-param 指向 spring-mvc.xml，基本就是正统 SSM。区分 SSM 和「Spring + Hibernate」的关键点在于 MyBatis 那一侧——只要出现 SqlSessionFactoryBean 的 bean 定义，以及一堆 mapper XML，就实锤了。

目录结构一般是这个样子：

项目名/ ├── pom.xml ├── src/main/java │ ├── com/xxx/controller # Controller 层，接 HTTP 请求 │ ├── com/xxx/service # Service 接口，定义业务方法 │ ├── com/xxx/service/impl # Service 实现，写业务逻辑 │ ├── com/xxx/mapper # MyBatis Mapper 接口，声明 SQL 方法 │ └── com/xxx/entity # 实体类，对应数据库表 ├── src/main/resources │ ├── jdbc.properties # 数据库连接参数 │ ├── spring-mvc.xml # Spring MVC 配置 │ ├── applicationContext.xml # Spring 容器配置 │ └── mapper/*.xml # MyBatis 的 SQL 映射文件 └── src/main/webapp ├── WEB-INF/web.xml # Web 应用入口配置 └── 各种 JSP 页面

拿到 zip 先做这一件事：把src/main/java下面的包名路径从头到尾看一遍。如果 controller、service、mapper 分得清清楚楚，说明写这个项目的人思路是干净的，后面改起来顺；如果所有类都堆在一个包下面，你要有心理准备，那多半是到处复制粘贴拼出来的，跑通容易，改起来难受。

2.2 SSM 各层为什么这样分：一次请求走完三层要经过什么

SSM 把 Web 层、业务层、数据层的边界画得很清楚，这也是当年高校项目普遍选它而不是直接上 Spring Boot 的原因。一个请求从浏览器发出到页面渲染完，大概是这么走：浏览器发 HTTP 请求 →web.xml里的 DispatcherServlet 接住 → 根据@RequestMapping找到对应的 Controller 方法 → Controller 调 Service 接口 → Service 实现类里写业务逻辑 → 调 Mapper 接口 → MyBatis 根据接口方法绑定 XML 里的 SQL → JDBC 访问 MySQL → 结果一层层返回 → Controller 用@ResponseBody直接写回 JSON，或者返回视图名让 DispatcherServlet 去解析 JSP。

分层意思是：Controller 里不写 SQL，Service 里不碰 HTTP 请求对象，Mapper 里不写 if else 业务判断。这样做的直接好处是，加一个新功能你知道代码落在哪个包，出问题你知道去哪一层找。比如「按地区筛选风俗条目」这个功能，Controller 只管接收region参数，Service 只管调 Mapper 并处理返回结果，SQL 只写在 mapper XML 里，三层互不越界。Spring Boot 把这些全自动配好了，对初学者反而成黑匣子，一旦启动失败根本不知道是哪一环断了；SSM 至少让你能看到每一根管线是怎么接起来的。

2.3 风俗文化管理系统的功能模块和数据表长什么样

「风俗文化」这个主题落到管理系统里，功能边界一般是两类界面。前台是展示侧：风俗文化条目列表、按分类筛选（传统节日、民俗技艺、地方美食、非遗项目这几类最常见）、按地区筛选、点进详情页看图文介绍。后台是管理侧：管理员登录、风俗条目管理（增删改查）、分类管理、公告管理、管理员账号维护。有的项目还会加 banner 轮播图和图片上传，这些属于加分项，不做也不影响主流程。

对应的数据库表一般五张起步：

看 SQL 文件时重点确认两件事。第一，t_culture表里有没有region字段，有它才能做地区筛选，否则前台那个地区下拉框就是空转；第二，t_admin表里有没有初始数据，很多课设项目把默认账号密码写在insert into语句里，你后面登录系统要回去翻这段，而不是在页面上瞎猜。

3. 本地跑通全流程：从数据库初始化到 Tomcat 成功启动

3.1 环境版本对齐：SSM 老项目对 JDK 和 Tomcat 很挑剔

SSM 是十年前的组合，对运行环境相当挑剔。见过太多人用 JDK 17 去跑，结果 Tomcat 起不来，报错信息五花八门，最后发现是版本不兼容。我建议按这个组合来配：

JDK 版本是最大的坑。Spring 4.x 时代的东西在 JDK 11 以上会出现 CGLIB 代理异常、JSP 编译失败这类玄学问题，所以装一个 JDK 1.8 并在 IDEA 的 Project Structure 里把 SDK 指过去，能省掉后面一大半的排错时间。MySQL 用 8.0 也能跑，但要额外注意驱动类名和时区参数，这一点在 3.2 里单独讲。

3.2 建库与数据导入：SQL 文件别拿到手就往 MySQL 8 里怼

先把数据库建好，字符集指定成 utf8mb4，然后导入 SQL：

-- 建库，字符集必须指定，否则后面中文和生僻字都会出问题 CREATE DATABASE folk_culture DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 切换到目标库 USE folk_culture; -- 导入 SQL 文件，路径请换成你解压后实际的 sql 文件位置 SOURCE /Users/yourname/folk_culture.sql;

SOURCE后面要写绝对路径或者从当前目录能解析到的相对路径。这种方式比把 SQL 内容整个复制进命令行再回车靠谱，因为课设项目导出的 SQL 里经常有注释和特殊字符，复制粘贴容易截断。如果 SQL 文件里自带CREATE DATABASE语句，先确认它建的库名和你预期一致，不一致就原地改掉，否则后面 jdbc 连错库，页面全空。

接下来改jdbc.properties，这是整个项目能不能连上数据库的命门：

# MySQL 5.x 用这个驱动；MySQL 8.x 要换成 com.mysql.cj.jdbc.Driver jdbc.driver=com.mysql.jdbc.Driver # 连接地址，库名、编码、时区参数都要对 jdbc.url=jdbc:mysql://localhost:3306/folk_culture?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的密码

三个参数分别说。useUnicode=true&characterEncoding=utf8是必须带的，少了它中文写入数据库直接变问号；serverTimezone=Asia/Shanghai是 MySQL 8 的强制要求，不填会报时区错误，MySQL 5.7 填了也没关系；驱动类名方面，MySQL 5.x 用com.mysql.jdbc.Driver，MySQL 8.x 用com.mysql.cj.jdbc.Driver，两个都写进 pom 但版本配错时，启动会报 ClassNotFoundException。改完配置，先单独在命令行里用 mysql 客户端连一下，确认账号密码没问题，再做下一步。

3.3 部署与启动：IDEA 图形化操作和 Maven 命令行两条路

我最常用的方式是 IDEA 加 Tomcat。操作路径是：Run → Edit Configurations → 左上角加号 → Tomcat Server → Local。然后切到 Deployment 选项卡，点加号选 Artifact，把这个项目的 war exploded 加进去。如果 Artifact 列表是空的，先回到 Project Structure → Artifacts → 加 Web Application: Exploded，把项目根目录指对。Application context 建议设成/或者/folk_culture，记下这个值，访问地址靠它。

如果你拿到的项目是 Maven 工程，并且 pom 里配了tomcat7-maven-plugin，那命令行也能直接跑：

# 在项目根目录（有 pom.xml 的那层）执行 mvn clean mvn tomcat7:run

这个命令会先把项目编译打包，再由 Maven 内嵌的 Tomcat 启动 Web 应用。日志出现INFO: Server startup in 1234 ms就算启动成功。注意插件名是tomcat7，不是tomcat8或tomcat9——这是历史遗留命名，它的 Servlet 版本对应 Tomcat 8 的规范，跑 SSM 项目完全够用。

另一种常见做法是打成 war 包手动扔进 Tomcat 的 webapps 目录：

# 打 war 包 mvn clean package -DskipTests # 把 war 复制到 Tomcat 的 webapps 下 cp target/folk_culture.war $CATALINA_HOME/webapps/ # 启动 Tomcat $CATALINA_HOME/bin/startup.sh # 看启动日志 tail -f $CATALINA_HOME/logs/catalina.out

war 包丢进去之后 Tomcat 会自动解压，访问地址就是http://localhost:8080/folk_culture/。这种方式的好处是贴近生产环境，坏处是每次改代码都要重新打包，调试效率低。我一般只在验证最终成品时才走 war 包流程，日常开发用 IDEA 的 exploded 模式，改完 JSP 刷新页面就能看到效果。

3.4 第一次访问：入口、默认账号和日志怎么看

启动成功后在浏览器输入http://localhost:8080/项目名/，正常情况下会进入首页，可能是风俗文化列表，也可能是引导页。如果首页空白或者 404，先试几个常见入口：/login、/admin/login、/admin/index。SSM 项目里登录页往往才是真正的入口，首页只是一个空壳跳转。

默认账号不要猜，回到 SQL 文件里搜insert into t_admin，账号密码就在那行数据里。很多课设项目的密码是 MD5 加密的密文，你没法直接看明文，那就用 SQL 更新一条已知密码的记录，比如把密码更新成123456的 MD5 值，然后去登录。启动日志里看到Deployed application和Server startup这两行，说明 Web 容器已经就绪。如果 IDEA 里 Tomcat 显示绿灯但浏览器连不上，八成是 Application context 或 Artifact 没配对，回 3.3 检查。

4. 风俗管理里的 SSM 常用注解：三层注解与参数传递的配合

4.1 Controller 层：@Controller、@RequestMapping、@ResponseBody 怎么配合

Controller 是 SSM 项目里注解密度最高的地方。看一个「按分类查风俗条目」的例子：

@Controller @RequestMapping("/culture") public class CultureController { @Autowired private CultureService cultureService; // 走 JSP 视图：接收分类参数，把数据塞进 Model，返回视图名 @RequestMapping("/list") public String list(@RequestParam(value = "categoryId", required = false) Integer categoryId, Model model) { List<Culture> list = cultureService.queryByCategory(categoryId); model.addAttribute("cultureList", list); return "culture/list"; } // 走 JSON 接口：用 @ResponseBody 直接把对象序列化成 JSON 写回浏览器 @RequestMapping(value = "/detail/{id}", method = RequestMethod.GET) @ResponseBody public Culture detail(@PathVariable("id") Integer id) { return cultureService.getById(id); } }

@Controller让 Spring 容器把这个类注册成一个 bean；@RequestMapping决定 URL 到方法的映射关系，类上的/culture加上方法上的/list，完整的访问路径就是/culture/list。@RequestParam用来取 query string 里的参数，required = false表示这个参数可以不传，不写的话前端少传一个字段后台直接报 400。@PathVariable用来取 URL 路径里的变量，对应/detail/{id}这种风格。

@ResponseBody是最容易误解的注解。写上它，方法返回值会被 Jackson 转成 JSON 写回响应体；不写它，Spring MVC 会把返回的字符串当成 JSP 文件名去解析，于是你看到报错Unable to resolve view with name 'xxx'。如果整个类都是返回 JSON 的接口，直接把@Controller换成@RestController，效果等同于每个方法都加了@ResponseBody。但要注意，传统 SSM 项目里很可能是 JSP 和 JSON 混着用，这时别图省事换@RestController，否则原来返回视图名的 JSP 方法全部失效。

4.2 Service 层：@Service 注册 bean，@Transactional 圈定事务边界

Service 层的注解比 Controller 少得多，但作用更重：

@Service public class CultureServiceImpl implements CultureService { @Autowired private CultureMapper cultureMapper; @Transactional @Override public void addCulture(Culture culture) { cultureMapper.insert(culture); // 如果 insert 之后这里抛出 RuntimeException 异常， // 事务会回滚，前面的 insert 不会写进数据库 } }

@Service是 Spring 给业务层准备的组件注册注解，效果和@Component一样，但语义更明确，包扫描时也方便按层过滤。@Transactional表示这个方法运行在事务里，Spring 会使用 AOP 在方法前后开启和提交事务。

有一个关键边界要说清楚：@Transactional默认只对RuntimeException回滚。如果你在方法里手动try catch吃掉异常，或者抛出的是受检异常（比如Exception的子类），事务不会回滚。这也是很多老项目「数据明明保存失败却写进去了」的原因。正确做法是让异常从方法里抛出去，或者显式指定rollbackFor = Exception.class。另外@Transactional只对public方法生效，写在 private 方法上编译器不报错，但运行时不生效，这个坑排查起来很隐蔽。

@Autowired默认按类型注入。如果同一个接口有多个实现类，直接注入会报NoUniqueBeanDefinitionException，解决办法是配上@Qualifier("beanName")指定注入哪一个。新手常见的翻车操作是：在 Service 实现类里用@Autowired注入自己，或者在 Controller 里直接注入 Mapper，这会绕过 Service 层，短期能跑，但事务和业务逻辑全废了。保持 Controller → Service → Mapper 的调用链，SSM 这套架构才有意义。

4.3 Mapper 层：@Repository 不是必须，@Param 才是多参数的关键

Mapper 是 MyBatis 的核心，它只是一个接口，真正的 SQL 在 XML 里。看这段：

@Repository public interface CultureMapper { // 单参数：不需要 @Param，MyBatis 能直接识别 Culture selectById(Integer id); // 多参数：必须用 @Param 给参数命名，否则 MyBatis 报错 List<Culture> selectByCondition(@Param("categoryId") Integer categoryId, @Param("region") String region); }

对应的 SQL 映射文件：

<select id="selectByCondition" resultType="com.example.entity.Culture"> select * from t_culture <where> <if test="categoryId != null"> and category_id = #{categoryId} </if> <if test="region != null and region != ''"> and region like concat('%', #{region}, '%') </if> </where> </select>

@Param是 SSM 常用注解里最容易被忽略的一个。MyBatis 在接口方法只有一个参数时，可以直接用参数值；一旦参数个数超过一个，就必须用@Param给每个参数起名字，否则 MyBatis 会报Parameter 'xxx' not found. Available parameters are [arg1, arg0]。这个报错信息很多人第一次见都不知道在说什么，其实就是少写了@Param。

XML 里resultType写的是实体类的全限定名，这是最保险的写法。项目如果配了 typeAliases 包扫描，可以简写成别名，但课设项目不一定配置了，写全限定名永远不出错。<where>和<if>是 MyBatis 动态 SQL 的核心，<where>标签会自动处理掉第一个条件前面的多余and，这也是你看到 SQL 里第一行没有 where 关键字但能正常执行的原因。#{categoryId}是预编译占位符，MyBatis 会把它转成?传给 JDBC，天然防 SQL 注入；如果你在 XML 里看到${}，那是字符串拼接，存在注入风险，验收前重点排查这个。

4.4 注解生效的前提：包扫描和注解驱动必须双双到位

注解写得再漂亮，Spring 容器不扫描也是白搭。SSM 项目里有两个配置文件各管一摊：applicationContext.xml负责扫描 Service 和 Mapper，spring-mvc.xml负责扫描 Controller。看spring-mvc.xml的关键配置：

<!-- 扫描 Controller 层，让 @Controller 和 @RequestMapping 生效 --> <context:component-scan base-package="com.example.controller" /> <!-- 开启 Spring MVC 注解驱动，@ResponseBody/@RequestBody 等全靠它 --> <mvc:annotation-driven /> <!-- 把静态资源请求放给默认 Servlet 处理，避免 CSS/JS 被 DispatcherServlet 拦截 --> <mvc:default-servlet-handler />

<mvc:annotation-driven />是容易漏掉的一行。没有它，@RequestMapping能识别但@ResponseBody不生效，接口返回的是一串字符串而不是 JSON。<mvc:default-servlet-handler />负责放行静态资源，不写这行的症状是页面能出来但样式全丢，CSS 和 JS 全部 404——这个我在第 5 章还会单独展开。

applicationContext.xml里的扫描范围要覆盖 service 和 mapper。注意两个文件的扫描范围不要重叠，如果spring-mvc.xml把 service 也扫了一遍，Spring 容器里会出现两个同名 bean，运行时会有一些看起来不可理喻的注入报错。一个简单的约定是：mvc 文件只管 controller 包，applicationContext 文件只管 service、mapper、entity 包，各扫各的，互不越界。

5. SSM 项目避坑清单：没跑起来的项目问题出在哪

5.1 Tomcat 起不来：端口 8080 被占用

现象：IDEA 里点启动，控制台几秒后报红，提示Address already in use: JVM_Bind <null>:8080，Tomcat 闪退。

原因：8080 端口被本机其他进程占了。常见的是之前启动过的 Tomcat 没关干净，后台还挂着 java 进程；也可能是本地装了其他 Web 服务占了同一个端口。

解决：先找到占用端口的进程。Windows 上执行netstat -ano | findstr :8080，macOS/Linux 上执行lsof -i:8080，拿到 PID 后结束进程。如果这个端口确实不能动，可以换一个：IDEA 里 Edit Configurations → Tomcat Server → HTTP port 改成 8081，访问地址同步改成http://localhost:8081/项目名/。换端口前先确认端口没被防火墙拦，否则换了还是起不来。

5.2 日志显示启动成功但首页 404

现象：控制台出现Server startup in xxx ms，IDEA 显示 Tomcat 已启动，但访问http://localhost:8080/项目名/是 404。

原因：三种情况最常见。第一，Artifact 没部署，Deployment 面板是空的，项目根本没挂到 Tomcat 上；第二，Application context 和实际项目名不匹配，访问路径写错；第三，web.xml 里 DispatcherServlet 映射了/，而默认欢迎页index.jsp不在 webapp 根目录。

解决：先看 Tomcat 启动日志里有没有Deployed application这行，没有就回 Deployment 里加 Artifact。然后看 Application context 的具体值，它决定访问前缀。最后检查src/main/webapp下有没有 index.jsp，没有的话直接访问/login或/admin/login。血泪经验：Application context 以 IDEA 配置里显示为准，不以项目文件夹名为准。

5.3 中文乱码：问号还是乱码，定位在哪一层

现象：页面刷新后中文全是???，或者数据库里存进去是问号，查出来也是问号。

原因：字符集在某一环断了。常见的有四个位置：jdbc.url里没带characterEncoding=utf8；JSP 文件头没写pageEncoding="UTF-8"；数据库建库时不是 utf8mb4；Tomcat 的 URI 编码没设置。

解决：按顺序排查。先看连接参数，见 3.2 的 jdbc.properties；再看 JSP 头，<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>缺一不可；然后用 SQL 查数据库字符集，SHOW VARIABLES LIKE 'character_set%';确认 database 和 connection 都是 utf8 或 utf8mb4；最后在 Tomcat 的conf/server.xml里给 Connector 加上URIEncoding="UTF-8"。改完重启，刷新时强制忽略缓存（Ctrl+F5），别再用旧页面的乱码来判断结果。

5.4 启动报 BeanCreationException 或 ClassNotFoundException

现象：Spring 容器启动时抛异常，提示BeanCreationException、Cannot resolve class或ClassNotFoundException，堆栈里指向某个具体类名。

原因：两个方向。第一是 Maven 依赖缺失，pom 里引的依赖本地仓库没有，或者依赖版本冲突，Spring 找不到某个类；第二是环境不匹配，比如用了 JDK 17 跑 Spring 4，CGLIB 代理类生成失败。

解决：先在项目根目录执行mvn -U clean compile，看是不是依赖问题。如果编译通过但启动失败，把异常堆栈里第一个Caused by的类名复制到搜索引擎，查它属于哪个 jar，然后检查 pom 里有没有对应依赖。不要上来就重装环境，大部分情况是 IDEA 的 Maven 缓存坏了，点击刷新 Maven 项目重新导入就好。如果项目是手工导包的，检查WEB-INF/lib下缺了哪个 jar，从其他同类型项目里补齐。

5.5 页面能开但样式全丢：JS/CSS 被 Spring MVC 拦截了

现象：功能正常，列表数据也能出来，但整个页面没有样式，F12 控制台里全是 CSS 和 JS 的 404 报错。

原因：DispatcherServlet 配置了拦截/，也就是所有请求都先进 Spring MVC。静态资源请求没有对应的 Controller 方法，自然 404。这是<mvc:annotation-driven />配了但<mvc:default-servlet-handler />没配的典型表现。

解决：在spring-mvc.xml里加静态资源放行配置：

<mvc:default-servlet-handler /> <!-- 或者指定静态资源目录，两种写法二选一 --> <mvc:resources mapping="/static/**" location="/static/" />

同时检查 JSP 里引用 CSS 的方式。如果写的是href="css/style.css"，在带有多级路径的页面里会相对到错误位置，正确写法是用${pageContext.request.contextPath}拼绝对路径，或者用<base>标签。这个坑和框架版本无关，SSM 项目里普遍存在，排查时先看浏览器 Network 面板里的请求路径，比看 Java 日志更直观。

6. 给系统做一次业务闭环体检：验证功能值不值得继续投入

6.1 一条完整的业务链路怎么算跑通

项目能启动只是开始，SSM 系统的价值得靠业务闭环来证明。拿这个风俗文化系统，我会按这张清单走一遍：

走链路的时候我习惯开一个无痕窗口，模拟一个完全没登录过的用户从头操作。很多课设项目的问题就是在开发者自己已经登录的状态下测不出来，换个干净环境立刻暴露。

6.2 这套系统值不值得改造成 Spring Boot

体检完之后你心里要有个判断：它值不值得继续投入。如果这是毕业设计，老师要求 SSM 那这套直接能用，把功能边界打扎实、把 SQL 里的${}拼串改掉，答辩够用。如果老师要求 Spring Boot，迁移成本没有想象中高：MyBatis 的 XML 文件不用动，Mapper 接口不用动，SQL 全部是现成的；要改的是 Controller 层的注解风格，把@Controller+@ResponseBody换成@RestController，再把spring-mvc.xml和applicationContext.xml里的配置移进application.yml。

如果只是应付课程验收，我最优先修三处：登录权限拦截（Spring MVC 拦截器配一下就够）、图片上传路径改成绝对路径并做文件名重命名、检查所有 XML 里有没有${}需要换成#{}。这三处修完，系统从「能跑」变成「能演示」，验收的观感会有明显差别。

我以前接手过一个类似的二手民俗管理系统，卡在图片上传上三天——图片第一次能显示，第二次刷新就裂。后来发现是相对路径导致在不同目录层级下解析结果不一致，改成上传目录固定 + UUID 文件名后彻底消停。这种项目表面看是框架问题，实际是字符集、路径、部署方式这三座大山。你把这三样理清楚，SSM 这套东西就算真正吃透了。希望帮到你。

本文还有配套的精品资源，点击获取