基于SSM框架的校园零食商店系统设计与实现

1. 项目概述：校园零食商店系统到底在做什么

先说结论：这是一套完整的Java Web毕业设计项目源码，基于SSM框架（Spring + Spring MVC + MyBatis）构建，业务场景是校园里的零食在线商店。学生可以注册登录、浏览零食分类、加入购物车、下单购买，管理员可以在后台管理商品、处理订单、查看统计信息。

现在很多计算机专业的毕业设计题目都偏向这种“信息管理系统 + 电商交易”的组合，原因很简单：它不是一个纯粹的CRUD玩具，而是集成了用户认证、商品检索、购物车状态管理、订单状态流转、库存校验、权限控制这些真实业务逻辑的系统。你做完它，既能在毕业答辩里讲清楚业务闭环，又能展示SSM三大框架整合、Maven依赖管理、数据库设计这些企业级开发的基本功，覆盖面很够。

这套系统适合谁参考？本科应届计算机专业学生、正在准备毕设但不想从零造轮子的人、以及想用一套业务完整的项目来复盘SSM框架开发的Java学习者。全文我会按实际开发时的思维链路来讲——从整体设计、技术选型、环境搭建、核心模块实现，到典型坑位排查，你可以把它当一份“带着思路的源码笔记”来读。

2. 整体设计与技术选型：为什么是SSM而不是Spring Boot

2.1 SSM框架组合的历史定位

现在很多学校课程还在讲SSM，企业里Spring Boot早已成为主流，但毕业设计选SSM不亏。原因很现实：毕设最重要的事情不是“用最潮的技术”，而是“能用自己讲得清的技术，完成一个有业务深度的系统”，并应对答辩时老师的追问。SSM组合在数据访问层有MyBatis这种半自动ORM，业务层有Spring的依赖注入和声明式事务，表现层有Spring MVC清晰的前端控制器模型，每一层都能拆开讲原理，非常适合展示你对框架的理解程度。

如果你是Java方向的毕业生，毕设里能说清楚“请求从DispatcherServlet进来之后，怎么经过HandlerMapping、Controller、Service、Mapper查到数据库再返回JSON响应”这条完整链路，面试时也很加分。

2.2 系统模块划分

校园零食商店系统，我建议按角色划模块：前台用户端、后台管理端、公共基础模块三大块。

• 前台用户端：注册、登录、商品浏览与分页搜索、商品详情、购物车增删改、订单提交、我的订单列表、订单状态查询。
• 后台管理端：管理员登录、商品管理（增删改查、上下架、库存调整）、订单审核与发货（状态推进）、用户管理、销量统计。
• 公共模块：统一响应结果封装、统一异常处理、拦截器做登录校验、MD5加密工具类、分页工具/插件。

数据库层面，至少要有用户表、商品分类表、商品表、购物车表、订单表、订单明细表。这是电商类系统的标准六件套，其中订单表和订单明细表为什么要分开？因为一个订单对应多个商品，而明细表里冗余了购买时刻的商品快照信息（名称、单价、数量）。如果不冗余，商品后续调价或删除会导致历史订单无法还原，这是一个典型的数据库设计考点，答辩时老师几乎必问。

2.3 为什么数据访问层选了MyBatis

MyBatis在毕设场景里有几个没法拒绝的优势：SQL由开发者自己编写，遇到复杂查询——比如“按分类筛选 + 价格区间 + 商品名称模糊查询 + 分页”——你能精确控制SQL的执行计划，交作业时可以直接贴出SQL语句说明查询逻辑。它不像JPA那样自动生成SQL，一旦性能出了问题很难定位。再者，MyBatis的Mapper接口和XML映射文件分开的写法，天然符合分层思想，老师也看得懂。

校园零食这类场景，典型的复杂SQL不会太多，但不代表没有。比如“统计每个商品的销量并排序，关联分类名称，筛选上架状态的商品，分页返回”，这个用MyBatis写动态SQL非常顺手，用原生JDBC则极其痛苦。

3. 环境搭建与SSM整合细节

3.1 基础环境版本选择

这一节是很多新手卡壳的重灾区。SSM整合对版本极为敏感，不同的大版本组合行为差异巨大。为了方便复现，我直接给出我实测稳定的版本组合：

• JDK：1.8（必选，SSM原生项目用JDK8，越稳越好，不要在毕设里去挑战JDK17的兼容问题）
• Maven：3.6.3
• Tomcat：8.5.x
• Spring：5.2.x（5.2.22.RELEASE）
• MyBatis：3.5.x
• mybatis-spring：2.0.x
• MySQL：5.7（或8.x，注意驱动类名差异，我用的是老牌5.1.x驱动）
• 数据库连接池：Druid 1.2.x（也别迷信后来的版本，毕业设计够用就行）

这套组合能保证你在IDEA/Eclipse里导入后一顿配置，跑起来的概率最大。我见过有人用Spring 4.x + MyBatis 3.2 + 旧版JDK，然后在mapper动态代理上踩了一下午的坑，没必要。

3.2 三大配置文件这样写才清晰

SSM项目最怕的是配置文件满天飞却理不清关系。我的做法是分层存放，每个文件职责单一：

• applicationContext.xml：Spring根容器，只放Service层和Dao层的Bean扫描（context:component-scan base-package指向service和mapper），数据源、SqlSessionFactory、事务管理器都在这配。

• spring-mvc.xml：Spring MVC子容器，只扫描Controller包，配置注解驱动、静态资源放行、视图解析器、JSON消息转换器。注意，一定不要把Service和Mapper也放在这里扫描，否则会产生容器边界混乱的问题，比如事务失效。

• mybatis-config.xml：MyBatis全局配置，主要放驼峰命名映射（mapUnderscoreToCamelCase）、日志实现、类型别名包。

• jdbc.properties：数据库连接信息。

• web.xml：配置ContextLoaderListener加载Spring根容器，配置DispatcherServlet加载spring-mvc.xml，配置CharacterEncodingFilter解决POST乱码。

为什么Controller层要放在spring-mvc.xml里扫，Service/Dao层要放在applicationContext.xml里扫？这是SSM整合的经典问题——父子容器关系。如果都在子容器里扫描，Spring MVC初始化时会重复创建Service实例，并且事务管理器基于的增强对象可能是父容器里那一份，导致@Transactional不生效。你哪怕只是照着做，没有完全理解原理，也要把这一步先做对。

3.3 依赖范围陷阱：servlet-api与jsp-api

这个坑我在给学弟调项目时见过太多次了——项目里同时引入javax.servlet-api和tomcat自带的servlet，启动的时候报重复类或版本冲突。Maven里引入servlet-api和jsp-api时，scope一定要设为provided，意思是编译期和测试期用，运行时交给Tomcat容器提供，避免和容器自带类冲突。

<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency>

4. 核心模块实现要点与关键代码

4.1 用户注册登录：从MD5到拦截器

用户模块是每个系统的门面，这个模块完成度的高低，直接影响老师对你的第一印象。

注册环节，我建议前端做一次表单校验，后端Controller里做二次校验，Service里做业务校验（比如用户名是否重复）。密码不能明文入库，用MD5加盐的方式处理。也许你会说MD5不安全，网上现成的彩虹表一大堆——但作为毕设，MD5加盐已经完全满足教学要求，你在答辩时可以说“如果上线，可以升级为BCrypt算法”，这一句能展示你有安全扩展意识，就够了。

用户登录成功之后，我把用户信息放进Session，同时写一个LoginInterceptor拦截器，拦截除登录、注册、首页、商品列表以外的所有请求，判断Session里有没有用户对象。这里有一个很重要的细节：拦截器里要放行静态资源，否则CSS和JS都加载不出来，页面丑到没法看。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("user"); if (user == null) { // 如果是AJAX请求，返回JSON状态码；普通请求直接重定向 String requestedWith = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestedWith)) { response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录\"}"); return false; } response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

这里有一个区分“是不是AJAX请求”的小技巧：前端AJAX请求时主动添加X-Requested-With头，后端在拦截器里拿这个头来判断。如果你不加这个判断，用户会话过期后点击“加入购物车”，页面会被强行重定向到登录页，用户刚刚选好的零食全丢了，体验极差。这个细节，我强烈建议你写进答辩讲稿里，“登录状态校验对异步请求的差异化处理”，是一个很好的加分点。

4.2 商品模块：分页查询与条件组合

商品展示是整个商店系统的流量入口，也是业务逻辑最繁琐的部分。前台用户需要在“全部分类”和“某个分类”之间切换，同时能按价格排序，按关键词搜索。这里需要写一个组合条件的查询：分类ID可空、关键词可空、价格区间可空、排序字段可选。

MyBatis里用动态SQL解决：

<select id="selectProductList" resultType="com.shop.entity.Product"> select * from product <where> <if test="categoryId != null"> and category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> and (name like concat('%', #{keyword}, '%') or description like concat('%', #{keyword}, '%')) </if> <if test="minPrice != null"> and price &gt;= #{minPrice} </if> <if test="maxPrice != null"> and price &lt;= #{maxPrice} </if> and status = 1 </where> <choose> <when test="sortRule == 'price_desc'"> order by price desc </when> <when test="sortRule == 'price_asc'"> order by price asc </when> <otherwise> order by create_time desc </otherwise> </choose> </select>

这里有个新手容易犯糊涂的点：动态SQL里的 ，这个categoryId来自哪里？它来自Controller方法的参数绑定，通常是一个查询条件对象ProductQuery。前端把筛选条件通过URL参数或AJAX body传过来，Spring MVC直接绑定成对象，然后传给Service，Service再传给Mapper。

分页我同时实现了两种方案：物理分页（用PageHelper插件拦截SQL拼接limit）和手写分页（手动计算offset和limit）。毕业设计建议用PageHelper，它能让代码干净很多，但答辩时最好说明“底层是拦截器原理，对符合规则的原SQL做了一次count查询和一次limit改写”。能说出这句话，说明你真正理解分页插件，而不是停留在调用API层面。

4.3 购物车设计：Session存储还是数据库存储

这是这个项目里最值得展开讲的设计决策。

购物车有两种存储方式：Session存储和数据库存储。

Session存储的特点：实现简单、无需入库、用户关闭浏览器购物车就没了，适合访客临时加购的体验。数据库存储的特点：用户换设备、清缓存都能保留购物车，数据可持久化，但每次操作都要读写数据库，还得有一个购物车表。

校园零食商店的用户量不需要特别复杂，但为了突出系统的完整性和数据库设计能力，我推荐采用数据库存储方案。购物车表结构：

• id（主键）
• user_id（用户ID）
• product_id（商品ID）
• quantity（数量）
• create_time / update_time

在同一张表里，对（user_id, product_id）建唯一索引。用户把同一件零食再放一次进购物车，底层就会做一次“有则加数量，无则新增行”的upsert操作。

INSERT INTO cart (user_id, product_id, quantity) VALUES (#{userId}, #{productId}, 1) ON DUPLICATE KEY UPDATE quantity = quantity + 1;

MySQL的INSERT ... ON DUPLICATE KEY UPDATE，正好利用唯一索引实现“加购幂等”。这个细节在答辩时是个很好的亮点——你用数据库层面解决了并发重复加购的问题，比在Java代码里先查再插的思路更稳。不过要注意，这个方法依赖唯一索引，如果一张表忘了加索引，它执行的其实是普通插入，会出现重复购物车行，一定别漏。

4.4 订单状态机与库存扣减

下单是整个系统最核心、最容易被老师连环追问的一环。

订单状态我定义为：待付款（0）、已付款（1）、已发货（2）、已完成（3）、已取消（4）。每个状态之间能执行什么操作，是固定的，这就是状态机的基本思想。前端展示按钮时，根据状态渲染对应的操作，比如待付款状态显示“去支付”和“取消订单”，已发货状态显示“确认收货”，不能颠倒。

下单接口的事务逻辑，我按这个顺序写：

1. 校验购物车中选中的商品是否都有库存。
2. 计算订单总金额（注意这里的金额要从数据库查出的商品单价算，绝不能信前端传过来的总价，否则用户可以篡改请求数据把总价改成一毛钱）。
3. 扣减库存。这里用一个带条件的UPDATE语句做原子操作：UPDATE product SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}，返回影响行数，如果影响行数为0，说明库存超卖，直接抛异常回滚。
4. 生成订单主表记录。
5. 批量插入订单明细表。
6. 清空购物车中的对应商品。

整个过程用@Transactional包裹，任何一个环节抛异常，前面的数据全部回滚。

为什么第3步要写成“扣减库存 + 判断库存”的一条SQL，而不是先查库存再UPDATE？因为在并发场景下，两个用户同时看到库存还剩1件，你查出来各剩1件，然后都去更新库存，就会变成-1，造成超卖。用带条件UPDATE，数据库行锁机制保证同一时刻只有一个请求能成功扣减，天然挡掉了超卖。这个要点在毕业设计的“系统亮点”部分，一定要提。

订单号生成也不要偷懒用自增ID，我用的方案是：时间戳 + 用户ID后四位 + 随机数。这样订单号不会重复，也能从订单号反推大致时间，演示时也显得专业。

4.5 后台管理：参数校验与日志埋点

管理端的功能主体是商品CRUD和订单状态推进，技术栈和前台用户端一样，区别在于多了角色权限校验。最简单的方式是加一个AdminInterceptor，拦截/admin/路径，检查Session里的管理员身份。这种“按URL前缀做粗粒度权限控制”的做法，对毕设来说足够，答辩时也容易解释。

商品新增或修改时，我额外加了一些细节：商品主图和轮播图的上传，保存到本地磁盘目录，数据库只存访问路径。生产环境通常需要上OSS云存储，但毕设项目存本地完全合理，唯一要注意的是保存路径和Tomcat部署路径别搞混了。用绝对路径存图片目录，然后用配置项映射成URL访问，比把图片塞进项目目录要稳得多。

订单审核部分，后台管理员点击“发货”，相当于把订单状态从已付款推送到已发货，此时我记录一个发货时间，用户端“确认收货”后再把状态从已发货推送到已完成。这就是业务的状态流转闭环。

我还给管理员加了一个简单的统计页：按天统计订单数和销售额，用一条带DATE_FORMAT的SQL搞定。这个功能虽然简单，但让整个后台显得有“运营感”，比纯CRUD的观感好很多。

5. 实操过程与踩坑记录

5.1 从零开始搭建的完整步骤

如果你拿到的是别人分享的源码，我建议你不要直接导入就完事，最好自己从头搭一遍。哪怕不重写整套代码，至少要把“配置怎么连起来”这件事搞明白。我按实际操作顺序列一套步骤，你自己手敲一遍之后，再回来跑别人的源码，理解会深很多：

1. 创建Maven Web项目，配置pom.xml，引入spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid、jstl、jackson-databind、lombok（可选）。
2. 编写web.xml，配置ContextLoaderListener和DispatcherServlet。
3. 编写applicationContext.xml，配置数据源、SqlSessionFactoryBean（这里要指定mapper-locations和typeAliasesPackage）、MapperScannerConfigurer（自动扫描Mapper接口）、事务管理器、开启注解事务。
4. 编写spring-mvc.xml，配置包扫描、注解驱动、静态资源映射、JSP视图解析器（InternalResourceViewResolver，prefix=/WEB-INF/views/，suffix=.jsp）。
5. 编写Mapper接口 + XML映射文件，注意xml的namespace必须写Mapper接口全限定名。
6. 编写实体类、Service接口及实现类、Controller、前端页面。
7. 配置Tomcat，启动，逐接口调试。

5.2 三个让我折腾到半夜的问题

第一个是Maven依赖冲突导致的NoSuchMethodError。Spring 5.2和旧版javax.interceptor-api或者老版aspectjweaver混在一起，可能启动时报方法找不到。解决思路就是版本统一，用一个高版本的spring-boot-dependencies做BOM，或者手写一个依赖版本清单严格对齐。建议直接在pom里用dependencyManagement锁版本。

第二个是JSON的循环引用问题。用户实体里关联了订单列表，订单实体里又关联了用户对象，直接序列化会无限递归，结果是浏览器页面卡死，后台疯狂刷StackOverflowError。解决方法是给关联属性加@JsonIgnore注解。答辨时这是一个经典考点——“双向关联序列化怎么处理”，值得提前准备好答案。

第三个是最隐蔽的：Mapper接口和XML文件没扫描到。如果你的dao包是com.shop.dao，而MapperScannerConfigurer的basePackage写成了com.shop.mapper，那么Spring容器里根本没有Mapper接口的代理对象，Service注入那一环直接报UnsatisfiedDependencyException。检查思路就是：看启动日志里有没有出现类似“Bean named 'productMapper' is expected”的提示，有的话基本就是包扫描路径错了。

5.3 前端页面与异步请求的配合

这个项目的前端是JSP + JSTL + AJAX混用。JSP渲染首屏数据，AJAX处理购物车加减和订单状态更新这类局部操作，这是最典型的SSM项目风格，也符合老师的预期。

页面不用追求花哨，但一定要干净。我推荐用Bootstrap 4搭建页面框架，配合一小段自定义CSS，呈现出来的是简洁的后台管理系统风格。商品列表页的卡片布局、购物车的表格布局、订单列表的时间线布局，用Bootstrap的栅格就能快速实现，省下的时间全部用来打磨后端逻辑。

AJAX请求统一用$.post或$.ajax，约定返回格式为{code: 200, msg: "...", data: {...}}。前端根据code做分支，200就刷新局部页面，非200就弹alert展示msg。前端自己封装一个common.js，统一处理登录过期（code=401）时跳转登录页，这个细节能够避免每个页面都重复写一套判断逻辑。

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

6.1 经典问题速查表

6.2 排查思路分享：当启动报奇怪的Exception时

我给学弟调项目时最常用的套路是：先看异常栈的前八行，不一定是第一行，而是“Caused by”开始的那一段。Spring项目很多异常会被外层包装，真正的根因往往在嵌套的Caused by里。比如一个看起来很吓人的BeanCreationException，根因可能只是数据库名写错了。所以遇到报错不要慌，放大日志，一层层剥到最底层的“Caused by”，再对症下药。

6.3 答辩前必做的检查清单

离答辩还有三天的时候，不要再改功能了，按这个清单走一遍：

• 系统能否在干净的MySQL环境上重建数据库并成功导入初始化数据。
• 演示流程是否顺畅：注册新用户 → 登录 → 浏览商品 → 搜索 → 加购物车 → 结算下单 → 模拟支付 → 后台发货 → 确认收货。这条主链路走下来，每一步的“下一步按钮”都要明确可点。
• 几种异常分支提前想好：库存为0的商品不能下单，路由拦截后直接访问后台URL会跳登录，重复注册同一用户名会提示已存在。
• 代码里不要留调试用的System.out.println和临时注释。

7. 源码部署与二次开发扩展建议

7.1 拿到源码后先别急着打开IDE

先看README，再看数据库初始化脚本，然后建库，最后再导入工程。顺序搞反了，经常会出现“工程启动后找不到表”的尴尬情况。数据库脚本里如果是utf8mb4字符集，建库的时候也要用utf8mb4，否则中文搜索可能出问题。

导入到IDEA后，等待Maven下载依赖的同时，把配置文件的数据库账号密码改成自己的。特别注意时区参数serverTimezone，MySQL 8.x必须要带，否则连接会报时区异常。我的连接串是：

jdbc:mysql://localhost:3306/snack_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

7.2 适合在毕设中体现的扩展点

如果想让项目比同组同学高出一截，可以从下面这几个方向挑一个扩展：

• 增加“模拟支付”页面：不接真实支付，但做一整个支付流程的状态机，让订单从待付款走到已付款，这个流程让系统更完整，也让讲解更有说服力。
• 增加用户收货地址管理：用户下单选地址，而不是固定一条。这个功能加上去之后，订单表关联的是地址快照而不是用户ID，正好呼应了前面说到的快照思想。
• 增加MySQL索引优化说明：在商品表、订单表的常用查询字段上加索引，在答辩PPT里贴一张EXPLAIN的截图，说明加了索引前后rows的对比，老师会给你一个“有工程意识”的好印象。
• 前端改用Vue3 + Element Plus拆分前后端，后端提供RESTful API。这个是大工程，如果时间充裕、又有Vue3基础，可以考虑。但这里要提醒一下：毕设的原则是“不要为了炫技而冒险”，SSM + JSP是保底方案，前后端分离意味着你还需要处理跨域问题，万一前端构建环境有问题，整套系统就瘫了。

7.3 我个人对这些源码的使用建议

我见过不少同学从网上下载源码后直接交掉，结果答辩时老师随便问一句“你这个启动流程大概是什么样”，答不上来。源码是拿来学习的，不是拿来交付的。建议你把项目整体看一遍之后，自己手动删掉Service实现里的核心逻辑，然后重新写一遍。写完再对照原版，看差在哪里，这一步才是收获最大的。

8. 项目二次封装与代码健壮性的几个要点

8.1 统一响应结构是优雅的基础

我坚持把所有Controller返回值封装成Result类，里面有code、msg、data三个字段。这样无论正常还是异常，前端拿到的都是同一结构。有的同学每个Controller各写各的返回格式，有的返回Map，有的直接返回Entity，页面调用时还要分别判断，这种代码既难维护，答辩也是减分项。

统一异常处理也别漏。写一个@ControllerAdvice全局异常处理器，分三类处理：业务异常（BizException）返回400并携带提示信息，参数校验异常返回400并携带具体字段错误，未知异常返回500并记录日志。这样Controller里就不用写一堆try-catch，代码清爽很多。

8.2 参数校验不要全部依赖前端

前端表单校验再好，也拦不住用户直接用Postman请求接口。我在后端对关键参数也做了校验：价格必须大于0、库存不能为负、手机号格式、邮箱格式等。SSM环境里可以用Hibernate Validator做Bean Validation，也能手写工具类。毕设项目手写工具类就够了，不用引入太多依赖，但一定要有这一层意识。

8.3 关于密码和Session安全的个人建议

如果项目还有余力打磨，建议把Session的会话超时时间设置一下，默认30分钟比较合理。用户登录时可以增加一个简单的“记住我”逻辑：勾选之后把用户名Cookie化，下次登录自动带出，不存密码，只存用户名，这只是体验优化，不涉及安全风险。密码相关的细节刚才说了，MD5加盐足以应对毕设，但能在代码注释里写清楚为什么不用明文，就已经体现安全意识了。

最后多说一句

整个项目从前到后走完，你会发现SSM框架本身并不神秘：Spring管对象和事务，Spring MVC管请求路由，MyBatis管数据库读写。校园零食商店这个业务场景把这些知识点全部串了起来，你做一遍之后，很多课堂上似懂非懂的概念会突然串成一条线。这也是毕业设计最大的价值所在——它逼着你在一个具体场景里，把分散的技术点融会贯通。

做毕设的时候别贪多，把主链路跑通、把核心逻辑讲透，比堆一百个花哨的小功能更管用。希望这套拆解思路能帮你把这份源码真正消化成自己的东西，答辩时心里有底。