基于SSM+Vue的垃圾分类系统设计与实现：从积分闭环到前后端分离实战

分类垃圾这件事，这两年从小区楼下的桶到手机里的App，算是彻底走进了日常生活。作为一个常年和Java后端打交道的开发者，我接到过不少类似的课题需求，但“垃圾分类系统”这个方向，说实话是个挺有意思的切入点——它不像传统的电商管理系统那么枯燥，业务逻辑里天然带着“环保”、“激励”、“教育”三条线，做出来的东西既有社会价值，也有技术深度。

今天要分享的这个项目，编号SSM281，是一个基于SSM框架配合Vue前端实现的垃圾分类系统，核心模块除了最基础的垃圾类别查询和分类管理之外，还扩展了环保商城、积分礼品兑换、以及垃圾分类知识考试三个部分。这三个模块不是简单堆功能，而是形成了一个完整的业务闭环：用户查分类、答对题、买环保商品，都能获得积分，积分再去兑换礼品，整个流程既有实用价值又有激励效果。从课题设计的角度看，这种组合很聪明，它让系统不再是单一的信息展示工具，而是带上了用户运营和内容教育的属性。

对于正在做毕业设计、课程设计，或者是想熟悉SSM整合+Vue前后端分离开发流程的同学来说，这个项目是一个很好的完整范例。它覆盖了权限控制、订单状态流转、积分计算、考试组卷等典型业务场景，难度适中，又足够拿来扩展开题。接下来我会从设计思路、数据库建模、核心功能实现到踩坑实录，把整个项目掰开揉碎讲一遍。

1. 项目整体设计与模块拆解

拿到这类课题，第一件事不是急着敲代码，而是把业务逻辑梳理清楚。很多同学做管理系统容易陷入“增删改查”的死胡同，就是因为没有先想明白模块之间的关系和用户的使用路径。

1.1 核心需求解析：三个模块如何形成业务闭环

“垃圾分类 + 商城 + 礼品 + 考试”这四个关键词，表面上看是四块独立的功能，但在这个项目里，它们被一条隐形的线索串了起来——积分。

垃圾查询是系统的入口功能。用户输入垃圾名称，系统返回所属类别（可回收、有害、厨余、其他），并提供投放指导。这个模块是纯粹的查询工具，但它的意义在于建立用户对“垃圾分类”这件事的认知。

考试模块对应的是“教育”维度。系统内置垃圾分类题库，用户在线答题，按得分获得相应积分。这比单纯浏览分类知识更能让用户加深记忆，毕竟答题本身就是一种主动学习。

商城模块对应的是“日常消耗”维度。用户可以用现金购买环保主题商品（环保袋、水杯、分类垃圾桶贴纸等），下单后订单状态从待付款流转到待发货再到已完成。这类商城功能是常规电商系统的简化版，但订单和积分挂钩——消费也能攒积分。

礼品模块则是“激励”维度的终点。用户积累的积分可以兑换礼品（如文具、日用品、环保周边），兑换后库存减少、积分扣减。这样一来，用户每一次查垃圾、答题目、买商品，都变成了一个有反馈的行为，系统就有了粘性。

从课题评分的角度来看，这种设计也很有优势。它同时覆盖了信息管理、交易流程、激励体系、在线测试四类业务场景，答辩时能讲的东西非常多，代码量也能撑起一个完整项目的体量。

1.2 技术选型思路：为什么还是SSM + Vue

现在Java后端的框架选择其实很多，Spring Boot + MyBatis Plus已经是主流，但SSM（Spring + SpringMVC + MyBatis）依然是高校教学和课程设计的“标准配置”。

选择SSM而不是Spring Boot，主要有几层考虑。第一，SSM能让你手动处理大量配置——applicationContext.xml、spring-mvc.xml、mybatis-config.xml，每个配置项都要自己写，这个过程虽然繁琐，但对理解IoC容器、AOP代理、SqlSessionFactory创建等底层机制非常有帮助。第二，很多高校的软件工程课程、Java Web课程仍然以SSM为教学大纲，课题要求里如果明确写了“基于SSM框架”，用Spring Boot反而可能不符合要求。第三，部署环境通常是Tomcat 8 + JDK 1.8，SSM通过war包部署非常成熟，兼容性没有坑。

前端选Vue而不是JSP，是因为一是课程设计越来越看重前后端分离的架构意识，二是Vue + Element UI做后台管理界面效率极高。Vue CLI搭好工程、配好路由、用Axios发请求，前端开发的体验比JSP写脚本let脱离了一个时代。

1.3 角色权限设计：用户与管理员各管一摊

任何一个管理系统都有角色边界，这个垃圾分类系统也不例外。我把权限设计成两套角色，用拦截器统一控制访问路径。

用户端（前台）功能：

• 垃圾分类查询（支持模糊搜索）
• 在线考试答题、查看历史成绩
• 浏览商城、加入购物车、创建订单
• 查看个人积分、兑换礼品、查看兑换记录
• 个人信息修改

管理员端（后台）功能：

• 垃圾类别管理（增删改查）
• 垃圾信息管理（维护具体垃圾条目及分类规则）
• 题库管理（录入题目、选项、正确答案、分值）
• 商城商品管理（上架、价格、库存、封面图）
• 订单管理（发货、查看详情）
• 礼品管理与兑换审核
• 积分充值（特殊需求时后台手动调整）
• 用户列表与数据统计（答题通过率、商品销量排行等）

这个角色划分的逻辑很清晰——前台是“用”系统的人，后台是“管”系统的人。实现上，用户表和admin管理员表分开设计，session里存用户对象，拦截器判断session中是否包含对应角色标识。对于前后端分离项目，用session做登录态管理比JWT在课题答辩中更容易解释，而且Tomcat环境下天然支持，省去跨域和Token过期处理的复杂度。

2. 数据库设计与核心表结构

SSM项目的核心是MyBatis，MyBatis的操作对象是数据库表。表结构设计得好，后面的Mapper和Service写起来会顺畅很多；表设计不合理，后面的每一个查询都会变成噩梦。

2.1 整体表关系概览

我最终设计了9张核心表，它们的关系可以用一句话概括：用户是核心主体，垃圾信息和题库是基础数据，商品和礼品是业务载体，订单、答题记录、兑换记录是行为流水。

表清单如下：

这里有一个需要特别注意的点：用户积分我单独建了一张表，而不是在user表里直接加一个points字段。原因在于积分会被考试得分、订单金额转换、兑换扣减等多处业务修改，单独成表可以清楚记录积分变更的源头，未来如果扩展积分明细表（points_log），只需在user_points和points_log之间建立关联即可，不影响现有结构。

2.2 核心表结构设计解读

先说说user表。密码字段我用的MD5加盐处理——虽然现在有很多更安全的算法，但课题项目里MD5加盐已经足够证明你理解了“不能明文存储密码”的安全常识。username设置为唯一索引，登录时通过username查询，索引命中率高，性能没问题。

garbage_type表和garbage_info表是典型的一对多关系，通过type_id外键关联。我需要额外强调垃圾条目的name字段设计——它必须设计为varchar且建普通索引，因为用户查询垃圾分类的入口就是输入垃圾名称，后台用LIKE模糊匹配，索引能保证在数据量达到数千条时查询依然流畅。

exam_question表设计时，我把四个选项拆成了option_a、option_b、option_c、option_d四个独立字段，而不是用一个JSON字符串存所有选项。这样做的原因是方便Mapper直接用correct_answer字段与某个option字段做等值判断，例如correct_answer = 'B'，那么正确内容就是option_b。如果用JSON，判断答案时还需要前端或者后端二次解析，增加了复杂度，答辩时讲起来也绕。

order_table表是商城模块的流水表，status字段用int值表示状态流转：0待付款、1待发货、2已发货、3已完成、4已取消。这里不用字符串枚举是因为订单状态在代码里会有大量if判断和switch分支，int比字符串比较效率更高，也符合电商系统的常规做法。

gift表里有一个字段是points_cost，它是礼品模块的核心关联字段——用户兑换时，不仅会往exchange_record表插记录，还会扣减user_points表的total_points并校验积分是否足够。这块事务处理非常关键，后面实操部分我会详细说。

2.3 为什么这些表能支撑整个业务闭环

数据库表设计完毕，再回看这个业务闭环，数据传递链路是非常清晰的：用户通过exam_record获得分数 -> 根据分数计算积分 -> 积分累加到user_points -> 积分在gift兑换时扣减 -> 兑换动作写入exchange_record -> 礼品库存同步减一。与此同时，用户通过商城下单 -> 订单状态流转 -> 后台发货 -> 商品库存减少。两条线互不干扰，但它们共用user这张表作为主体关联，所有数据最终都能按用户维度聚合统计。

这种设计的直接好处是，答辩时老师问“积分从哪来、到哪去、系统中哪些操作会影响库存”，你都能用表关系图说清楚，代码里的每个Service方法都能对应到具体表的读写。对于课程设计评审来说，这种“讲得清”比“写得多”更重要。

3. 后端核心功能实现要点

后端是SSM三层架构，Controller -> Service -> Mapper。我按模块把实现过程中的关键逻辑和设计思路拆开讲，这些都是直接能落地的方案。

3.1 SSM整合的关键配置

SSM项目最容易让新手卡住的，就是三个配置文件互相依赖、加载顺序不对就会报各种诡异异常。我的配置方案如下。

web.xml中配置Spring容器监听器和SpringMVC的前端控制器DispatcherServlet。这里有个细节：ContextLoaderListener负责加载applicationContext.xml，DispatcherServlet负责加载spring-mvc.xml。前者是根容器，后者是子容器，子容器可以访问父容器的Bean，反之不行。所以Service和Mapper要放在applicationContext.xml扫描，Controller放在spring-mvc.xml扫描，否则会出现Controller能注入Service但Service无法注入Mapper的怪问题。

applicationContext.xml里配置数据源（Druid连接池）、SqlSessionFactoryBean、MapperScannerConfigurer、事务管理器。数据源用Druid而不是c3p0或dbcp，一是Druid自带监控页面，答辩时可以展示SQL执行情况；二是Druid的防SQL注入和连接池保活策略比老牌连接池更完善。

spring-mvc.xml配置注解驱动、静态资源放行、视图解析器。前端是Vue分离部署，后端接口返回JSON，所以不再配置JSP视图解析器，改为在方法上使用@ResponseBody注解，配置一个Jackson消息转换器处理JSON序列化即可。

mybatis-config.xml里必须配置驼峰映射——mapUnderscoreToCamelCase设为true。数据库字段是user_name这种下划线风格，Java属性是userName，不开启这个配置，查询结果就会全部为null，而且报错还不明显，只能通过debug观察到对象属性全是空值。

3.2 垃圾分类查询的模糊匹配实现

垃圾查询是系统的门面功能，用户输入“电池”或者“废电池”，系统都要能返回正确分类。

Mapper层的实现我用了动态SQL：

xml复制<select id="searchGarbage" resultType="com.example.entity.GarbageInfo">
    select gi.*, gt.type_name
    from garbage_info gi
    left join garbage_type gt on gi.type_id = gt.type_id
    <where>
        <if test="keyword != null and keyword != ''">
            gi.name like concat('%', #{keyword}, '%')
        </if>
    </where>
</select>

这里用了left join而不是inner join，是为了防止某条垃圾信息没有绑定类别时被过滤掉。实际测试时我发现，模糊搜索的准确率取决于垃圾名称录入的规范程度。数据录入时我建议把“废电池”、“电池（废旧）”、“蓄电池”这样同一物品的常见叫法都录进去，否则用户搜“废电池”能查到，搜“电池”反而查不到，体验很差。

3.3 商城订单流程：状态机设计

商品加入购物车、提交订单，这两步是商城模块最基础的部分。购物车我用的Java的Map在内存中保存，没有专门建购物车表——因为课题项目不需要记住用户上次的购物车状态，session级别的购物车足够支撑演示。

订单创建的核心逻辑在Service层：

java复制@Transactional
public boolean createOrder(Integer userId, Integer productId, Integer quantity) {
    Product product = productMapper.selectByPrimaryKey(productId);
    if (product.getStock() < quantity) {
        throw new RuntimeException("库存不足");
    }
    Order order = new Order();
    order.setUserId(userId);
    order.setProductId(productId);
    order.setQuantity(quantity);
    order.setTotalPrice(product.getPrice().multiply(new BigDecimal(quantity)));
    order.setStatus(0);
    order.setOrderTime(new Date());
    orderMapper.insert(order);
    productMapper.reduceStock(productId, quantity);
    return true;
}

注意这个方法加了@Transactional注解。商品库存扣减和订单插入必须在一个事务里完成，否则可能出现订单创建成功但库存没扣、或者库存扣了但订单没生成的中间状态。我在测试时专门模拟过这种场景——去掉事务注解后，在一个线程里并发下单，很快就能复现超卖现象（库存变负数），加上事务后问题消失。

订单状态的流转用常量或者枚举管理，不要在代码里散落裸数字：

java复制public interface OrderStatus {
    int UNPAID = 0;
    int UNSHIPPED = 1;
    int SHIPPED = 2;
    int COMPLETED = 3;
    int CANCELLED = 4;
}

管理员在后台点击“发货”时，订单状态从UNSHIPPED变更到SHIPPED，并记录发货时间。用户点击“确认收货”，从SHIPPED变到COMPLETED。状态变更逻辑写在一个Service方法里，每次变更前校验当前状态是否合法，避免跨状态跳转（比如从UNPAID直接跳到COMPLETED）。

3.4 积分规则与礼品兑换的事务边界

积分是这个系统的灵魂，我把积分规则设计成三条：

• 考试得分转积分：按实际得分一分一比一转换，考80分得80积分
• 商城消费返积分：订单金额每一元返1积分，向上取整
• 后台手动调整：管理员可以在后台为指定用户增减积分

积分转换业务中，最需要小心的是礼品兑换的并发问题。兑换操作涉及三步：校验积分是否足够、扣减积分、扣减礼品库存、插入兑换记录。这四件事必须在同一个事务里完成：

java复制@Transactional
public boolean exchangeGift(Integer userId, Integer giftId) {
    UserPoints points = userPointsMapper.selectByUserId(userId);
    Gift gift = giftMapper.selectByPrimaryKey(giftId);
    if (points == null || points.getTotalPoints() < gift.getPointsCost()) {
        throw new RuntimeException("积分不足");
    }
    if (gift.getStock() <= 0) {
        throw new RuntimeException("礼品库存不足");
    }
    ExchangeRecord record = new ExchangeRecord();
    record.setUserId(userId);
    record.setGiftId(giftId);
    record.setPointsUsed(gift.getPointsCost());
    record.setStatus(0);
    record.setExchangeTime(new Date());
    exchangeRecordMapper.insert(record);
    userPointsMapper.reducePoints(userId, gift.getPointsCost());
    giftMapper.reduceStock(giftId, 1);
    return true;
}

这里有两个容易踩的坑。第一个是乐观锁：如果两个请求同时读到积分都是100，同时兑换90积分的礼品，可能导致库存超发或积分扣成负数。我们用的是user_points表加version字段，UPDATE语句带上version条件：

sql复制update user_points set total_points = total_points - #{cost}, version = version + 1
where user_id = #{userId} and total_points >= #{cost} and version = #{version}

影响行数为1才说明更新成功，否则抛异常回滚。第二个坑是礼品兑换后的status字段——0表示待发放、1表示已发放。管理员在后台将兑换记录置为已发放后，礼品库存才真正意义上“少一件”，但这个设计里我直接在兑换时就减了库存，原因是防止用户多人在同一时间兑换同一礼品但后台还没有确认，导致超兑。实际项目中两种方案都有人用，课题项目里选择兑换即减库存更简单直观。

3.5 考试模块：随机组卷与成绩判定

考试模块本质上是一套“阈值判定式在线测试”，但也不是简单的遍历。为了让每次考试题目顺序不同、选项顺序不同（防作弊），我在Service层做了随机抽题：

java复制public List<ExamQuestion> generatePaper(Integer questionCount) {
    List<ExamQuestion> allQuestions = examQuestionMapper.selectAll();
    Collections.shuffle(allQuestions);
    return allQuestions.stream().limit(questionCount).collect(Collectors.toList());
}

这里用Collections.shuffle打乱题目列表，再截取前N条。这个方法有一个隐含假设：题库总量必须大于等于考题数量，否则limit取不到足够的题目，前端就是空白。所以录入题库时建议至少录入20道题，考试每次随机抽10道。

答题判定直接在Java代码里做字符串比较，correct_answer等于用户提交的答案就加分。我建议前端提交答案时，一次性提交所有题目答案的数组，这样后端只需要一次遍历、一次循环判分，再插入一条exam_record记录，事务简单清晰。千万不要每道题单独请求一次后端接口，那样既增加网络开销，也让中途断网时成绩状态不完整。

4. Vue前端搭建与交互实现

前端用的是Vue 2 + Element UI，配合Vue CLI构建工具。这种组合在课题项目里是性价比最高的选择——Element UI组件库开箱即用，表格、表单、弹窗、导航菜单都有成熟组件，不用自己一点一点写CSS。

4.1 前端项目结构与路由规划

我用Vue CLI创建工程后，目录结构按模块分离：

text复制src/
├── api/            // 封装Axios请求接口
├── assets/         // 静态资源
├── components/     // 通用组件
├── router/         // 路由配置
├── store/          // Vuex状态管理
├── views/          // 页面视图
│   ├── front/      // 前台页面：首页、查询、考试、商城、礼品
│   └── admin/      // 后台页面：分类管理、题库管理、商品管理、订单管理、礼品管理
├── App.vue
└── main.js

路由设计上，我使用了懒加载的方式：

javascript复制const routes = [
  { path: '/', component: () => import('./views/front/Home.vue') },
  { path: '/exam', component: () => import('./views/front/Exam.vue') },
  { path: '/shop', component: () => import('./views/front/Shop.vue') },
  { path: '/gift', component: () => import('./views/front/Gift.vue') },
  { path: '/admin/login', component: () => import('./views/admin/Login.vue') },
  { path: '/admin/products', component: () => import('./views/admin/ProductManage.vue') },
  // more routes...
];

懒加载的好处是首屏加载时不用把全部页面代码一次性拉下来，项目功能较多时页面切换更快，答辩演示时也更流畅。

4.2 Axios拦截器与登录态管理

前后端分离项目最核心的问题就是登录态怎么保持。我用的是session方案，前端每次请求自动带上Cookie。Axios封装时加了一个请求拦截器和一个响应拦截器：

javascript复制axios.interceptors.request.use(config => {
  // 请求到达前，可以在这里统一加token或loading效果
  return config;
}, error => Promise.reject(error));

axios.interceptors.response.use(response => {
  const res = response.data;
  if (res.code === 401) {
    // 未登录或session过期，跳转登录页
    router.push('/login');
  }
  return res;
}, error => Promise.reject(error));

这样处理后，前端所有接口请求都不需要单独处理“未登录”的逻辑——只要后端返回401状态码，就统一跳转登录页。我在后端用拦截器实现这个校验：

java复制public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
    HttpSession session = request.getSession();
    if (session.getAttribute("user") == null) {
        response.setStatus(401);
        return false;
    }
    return true;
}

4.3 三个核心页面的交互细节

垃圾分类查询页是我花心思最多的页面。用户输入关键词后，通过Axios请求后端接口，返回的列表用卡片式布局展示，每张卡片显示垃圾名称、所属类别图标和投放建议。分类图标用不同底色区分——可回收用蓝色、有害用红色、厨余用绿色、其他用灰色。这个视觉区隔虽然简单，但用户一眼就能看出分类结果，比单纯文字体验要好很多。

考试页的交互流程是：进入开始考试 -> 按顺序展示题目，单选按钮选择 -> 点击下一题切换 -> 做完最后一题点击交卷 -> 弹出成绩确认框 -> 提交到后端。需要注意交卷按钮的状态：只有全部题号对应答案都不为空时才允许点击，否则给出“还有未作答的题目”的提示。这个校验放在前端做，可以避免后端多次返回异常。

商城页的购物车交互用了Vuex存储购物车数据，包括商品id、数量。点击“加入购物车”时，判断购物车里是否已有同款商品，有就数量加一，没有就新增一条。提交订单时，把整个购物车数组传到后端，后端循环创建订单记录。这里有个细节需要注意：如果购物车商品有若干项不同商品，订单金额是各自商品小计之和，但order_table表的设计是一张订单对应一个商品（每条商品独立订单），那么提交购物车时就要循环插入多条订单记录。只要把循环插入放在同一个事务里，就能保证要么全部成功，要么全部回滚。

礼品兑换页的交互相对简单，但我会在卡片上明确展示用户当前剩余的积分，以及每个礼品的积分价格。积分不足时，兑换按钮置灰并悬浮提示“积分不足”，这样用户体验会友好很多。

4.4 管理员后台的开发要点

后台和前台的开发节奏不太一样。前台注重交互体验，后台更注重数据的清晰展示和操作效率。

垃圾类别管理页面用Element UI的Table组件展示数据，操作列里有“编辑”和“删除”按钮。删除操作一定要用弹窗确认，避免误删。因为garbage_info表通过type_id关联garbage_type表，删除类别前要先检查该类别下是否有垃圾条目——有的话要么先删掉条目，要么禁止删除类别。我在后端Service里实现了这个关联校验：

java复制public boolean deleteType(Integer typeId) {
    int count = garbageInfoMapper.countByTypeId(typeId);
    if (count > 0) {
        return false; // 有垃圾条目引用，禁止删除
    }
    garbageTypeMapper.deleteByPrimaryKey(typeId);
    return true;
}

题管理页面有一个知识点详细讲解：题库的excel导入。如果20道题一道道手动在表单里录入，效率太低。我写了一个Excel导入功能，前端用Element UI的Upload组件上传xlsx文件，后端用EasyExcel解析，逐行插入exam_question表。这一步虽然花了一些时间，但是录题效率提高了十倍以上。如果课题时间紧，也可以用前端复制粘贴JSON的方式，把题目写成一个JSON数组粘贴到文本框里，一次性批量提交。

商品管理的图片上传也是一个坑点，后面我会专门讲。

5. 常见问题与排查技巧实录

实际开发这个项目时，我踩了不少坑，有些问题现在回想起来挺经典的，拿出来分享给各位，能让你们少走一些弯路。

5.1 经典问题：中文乱码

在SSM项目中，前端Vue通过Axios发送POST请求，默认Content-Type是application/json;charset=UTF-8，后端SpringMVC接收时如果字符编码过滤器配置不正确，中文很容易乱码。

解决方案有两个关键点。第一，web.xml中配置CharacterEncodingFilter，强制编码为UTF-8：

xml复制<filter>
    <filter-name>characterEncodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>forceEncoding</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>

注意forceEncoding参数必须设为true，否则如果请求已经带有Content-Type，过滤器可能不会用力修改编码。

第二，后端响应数据库查询的中文数据时，如果SpringMVC的RequestMappingHandlerAdapter没有配置消息转换器，返回的JSON中文可能乱码。我在spring-mvc.xml里做了如下配置：

xml复制<mvc:annotation-driven>
    <mvc:message-converters>
        <bean class="org.springframework.http.converter.StringHttpMessageConverter">
            <property name="supportedMediaTypes">
                <list>
                    <value>text/plain;charset=UTF-8</value>
                    <value>text/html;charset=UTF-8</value>
                </list>
            </property>
        </bean>
        <bean class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter"/>
    </mvc:message-converters>
</mvc:annotation-driven>

5.2 MyBatis查询结果字段为null

这个问题出现的场景是：数据库字段用下划线（garbage_name），Java实体类用驼峰（garbageName），查询返回的对象里这个字段为null，其他字段正常。

原因就是MyBatis默认不开启驼峰映射。解决方式是在mybatis-config.xml中配置：

xml复制<settings>
    <setting name="mapUnderscoreToCamelCase" value="true"/>
</settings>

配置之后，MyBatis在将ResultSet映射为JavaBean时，会自动将garbage_name映射到garbageName属性。如果配置了还不行，检查一下是不是Mapper.xml中使用了resultMap而不是resultType——resultMap需要手动配置列名与属性的对应关系，驼峰映射对resultMap部分场景不生效。

5.3 跨域请求导致session丢失

前端开发服务器默认是localhost:8080，后端是localhost:8081，两者端口不同，就存在跨域问题。如果后端没有开启CORS，前端请求会被浏览器拦截；如果CORS配置不对，session的Cookie也不会正常写入。

我推荐在spring-mvc.xml中配置CORS：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:8080")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

这里的关键是allowCredentials(true)必须开启，否则浏览器拒绝携带Cookie，session也就无法维持。

另外，Vue的Axios请求也需要设置withCredentials: true：

javascript复制axios.defaults.withCredentials = true;

只有前后端同时允许携带凭证，session方案才能完整工作。

5.4 图片上传的路径问题

商品封面、礼品图片都需要上传。前端用Element UI的上传组件，后端接收MultipartFile对象并保存到服务器磁盘。

这里最大的坑是保存路径和访问路径的不一致。我把图片保存到本地磁盘的一个upload目录，但前端要通过URL访问图片，就需要在SpringMVC中配置静态资源映射：

xml复制<mvc:resources mapping="/upload/**" location="file:D:/upload/"/>

把upload目录映射到虚拟路径/upload/下面。这样前端img标签的src就可以直接写http://localhost:8081/upload/xxx.jpg。

部署到Linux服务器时，路径又要相应修改，所以我建议把上传路径配置到properties文件中，通过@Value注入，部署时只需要改配置文件，不用改代码。

5.5 Session过期与用户操作冲突

用户长时间不操作页面，session过期后，点击“提交订单”或者“兑换礼品”时，后端拦截器返回401，前端Axios响应拦截器会自动跳转到登录页。看起来功能没问题，但有一个细节：用户重新登录后，他之前填写到一半的内容全部丢失了。

这个问题的优化思路是，在前端跳转登录页之前，将当前页面的关键数据存到localStorage，登录成功后再恢复。比如考试页，做题做到第8题时session过期，重新登录后应该恢复到第8题继续作答，而不是重新考一遍。这一层体验优化虽然不复杂，但在答辩演示时非常加分，说明你考虑到了用户使用场景的完整性。

5.6 并发下单导致库存超卖

我在本地测试模拟场景：开两个线程同时请求购买同一个商品，每个线程买1件，但商品库存只有1件。不加任何控制时，两个请求都能返回成功，库存变成-1。

解决方式就是依赖数据库的行级锁。在Mapper层写一个带条件的更新SQL：

sql复制update product set stock = stock - #{quantity}
where product_id = #{productId} and stock >= #{quantity}

更新影响行数为1时，说明扣减成功；影响行数为0时，说明库存不足，需要回滚并提示。这个方案比select出来判断再update更安全，因为数据库的行锁能保证update操作串行执行，不会出现两个线程同时读到库存1同时更新成功的情况。

6. 项目部署与演示注意事项

代码写完之后，部署到服务器上才能真正完成课题交付。这个环节也有不少经验值得分享。

6.1 手动war包部署还是IDE内置Tomcat

前端Vue项目通过build命令打包成静态文件，后端SSM项目打包成war包。war包既可以扔到Tomcat的webapps目录下部署，也可以用IDEA集成的Tomcat运行。

如果只是答辩演示，IDEA内置Tomcat运行后端的war包就足够了，前端用npm run serve启动开发服务器，两个服务都在本机，演示方便。但SaaS部署或给老师远程访问就需要正式的Linux部署。我在实践中总结的最稳妥方案是：

1. 后端打war包，放到Tomcat的webapps/ROOT下
2. 前端npm run build打包，生成dist目录，把dist里的文件拷到Tomcat的webapps/ROOT下
3. 这样同一个Tomcat端口同时托管前端页面和后端API，不需要配置跨域，Cookie也不会丢失

这个方案最大的好处是能避免跨域和session问题。前端访问http://服务器IP:8080/，后端接口访问http://服务器IP:8080/api/，同源环境下一切顺利。

当然，前端路由如果你用了history模式，刷新页面时可能会404，需要在Tomcat里配置RewriteValve或者改用hash模式。因为没有对应的Tomcat配置会踩坑——我在项目中最终用了hash模式路由，URL中是带有#号的，虽然不太好看，但部署稳定性最高，刷新任何页面都不会出问题。

6.2 答辩演示时的操作顺序建议

答辩演示是一门技巧活，操作顺序不对容易翻车。我的建议是：

1. 先演示查询功能，输入一个常见的垃圾名称（如“香蕉皮”），展示分类结果和投放指南
2. 再演示考试功能，快速完成一次答题，展示成绩和积分增加
3. 进入商城，选择商品加入购物车、提交订单
4. 去礼品模块，使用刚才考试获得的积分兑换一个礼品
5. 切换管理员后台，展示垃圾类别管理、商品管理、订单管理等页面

这套演示路径有一个很好的逻辑递进：查询建立认知 -> 考试验证学习 -> 商城产生订单 -> 积分兑换形成闭环 -> 后台管理展示完整性。每一步之间都有因果关系，老师顺着你的思路看完整个闭环，对项目的结构就会非常清晰。

如果时间紧张，只演示最核心的路径也可以，但积分兑换一定要演示，因为它是连接各模块的桥梁。不演示兑换，老师可能看不出为什么要把商城、考试、礼品放在同一个系统里，课题的整体设计价值就被削弱了。

6.3 数据库初始化脚本的整理

交付课题时，数据库初始化SQL文件一定要整理干净。我建议按如下顺序编写sql文件：

1. create database
2. create tables（按照外键依赖顺序，先建父表再建子表）
3. 初始数据（默认管理员账号、基础垃圾类别、初始垃圾条目、题库20道题、演示商品5个、演示礼品5个）

另外，在SQL文件顶部写上注释，标注每张表的用途和核心字段的含义。老师拿到项目后第一件事往往是导入数据库看表结构，一个注释清晰的SQL文件会让代码评审环节顺畅很多。

7. 项目扩展思路与价值延伸

做完这个垃圾分类系统，我其实一直在想它还能怎么扩展。这个项目最大的特点在于业务闭环已经形成，任何一处扩展都不会突兀，反而能强化原来的闭环逻辑。

如果时间充裕，可以在模块层面做几个方向的迭代：

第一，增加积分明细表。现在积分只有总额，没有流水的概念。增加一张points_log表，每一次积分增加和扣减都记录原因（答题得分、订单返积分、兑换礼品），配合图表展示积分变化趋势。这是一次很小的改动，却能大幅提升系统的数据完整性和分析能力。

第二，垃圾识别的图像上传。现在查询只能靠关键词输入，拍照识别是真正贴近用户需求的功能。可以用TensorFlow Lite部署一个轻量级图像分类模型，支持常见几十种垃圾的识别。严格来说这属于人工智能内容的引入，技术上建议使用现有的预训练模型做迁移学习，数据量不必很大。但课题项目里引入AI模块属于“加分项”，但要注意工作量评估，别把AI部分搞成主线，SSM和Vue的核心功能才是基础。

第三，商城模块增加购物车数量和规格选择。目前购物车只支持单品数量，不支持规格（比如颜色、尺寸），如果扩展字段会涉及product表的规格表、订单表的快照字段等，代码改动量不小，但对于理解电商系统的复杂度很有帮助。

第四，社区功能。用户可以发帖分享分类小妙招，管理员审核后展示，系统从一个工具变成社区。这个扩展和垃圾分类的主题契合度高，也可以增加用户黏性。

8. 写在最后：这套代码背后的思维模型

最后聊几句项目之外的体会。做这个垃圾分类系统，我最大的收获不是SSM框架的标签背得有多熟，而是理解了一个道理：任何一套系统，即便功能再多，如果模块之间没有数据流转和逻辑闭环，它就是一盘散沙，无法真正体现“设计”这两个字。垃圾分类系统如果只有查询功能，那充其量是一个电子版分类手册；但加入考试、商城、礼品之后，它变成了一个可以激励用户持续使用的产品。这种“把孤立功能串成业务链路”的思维，是我在这个项目里最想传递的经验。

SSM + Vue这套技术组合，在2025年的今天看起来可能不算前沿，但它对于理解Java Web开发的底层机制依然有不可替代的价值。亲手配置一遍web.xml、调试一次Mapper映射、排查一个跨域问题，这些经历是直接上手Spring Boot的同学很难体会到的——框架帮你隐藏掉的复杂度，恰恰是你最好的学习素材。

如果你正在做类似课题，或者想练习SSM整合项目的开发能力，希望这篇拆解能给你节省几天的摸索时间。照着这个结构搭完之后，你会发现前后端分离没有想象中难，SSM也没有传说中的那么繁琐，真正的难点只在把业务逻辑想透，把表结构建好，剩下的都是熟练工。