莱夢最近来问毕设的学弟学妹里，十个有六七个都是电商购物类题目，其中“SSM+Vue冷冻饮品及甜品购物App”这个组合出现频率特别高。一面是冷冻饮品和甜品贴近日常生活，业务逻辑一目了然，用户端看商品、加购物车、下单，管理员端管商品、管订单，都是大家点外卖时天天在用的场景；另一面SSM（Spring+SpringMVC+MyBatis）+Vue这套技术在院校课程体系里覆盖率很高，参考资料多、老师熟悉，做起来心里有底。这篇文章就把我从选题、搭环境、写后端、写前端、联调、写论文这一整条链路里踩过的坑和总结出来的经验完整梳理一遍，给准备做同类型项目的同学一条可以直接照走的路线。
先把这个项目的定位说清楚。它本质上是一个移动端电商应用，卖的是冷冻饮品和甜品这类商品，核心用户角色有游客、普通用户和管理员。游客能浏览商品，注册登录后能加购物车、下单、管理收货地址，管理员在后台维护商品分类、上下架商品、处理订单状态。技术层面，后端用SSM三件套，前端用Vue框架配合Vant移动端组件库，整体是前后端分离结构。这里要特别说一句，标题里的“App”在本科毕设语境下，绝大多数指移动端适配的H5应用，也就是用Vue开发、以移动端浏览器方式访问的Web应用，后续可以用HBuilderX等工具二次打包成安卓安装包。这一点在开题和论文里都要写清楚，免得答辩时被老师追问。
1. 项目核心逻辑与功能模块拆解
1.1 用户侧和管理员侧各自要解决什么问题
任何电商系统，第一件事就是把角色和权限理清。这个项目里我把它分成三条线：游客、登录用户、管理员。
游客能做的事情很有限，浏览首页推荐、按分类查看商品列表、看商品详情，这些接口不需要登录态。一旦涉及到加购物车、提交订单、查看个人订单，就必须要求用户先登录。具体做法是在前端路由里配置路由守卫，后端在拦截器里校验Token，两边同时控制，缺一不可。
普通用户登录后的核心操作链路是：浏览商品 → 加入购物车 → 确认订单 → 填写或选择收货地址 → 提交订单 → 查看订单状态。这条链路是电商系统的命脉，也是论文里业务流程图的核心，建议画图时把这条主线画得足够清晰。
管理员端则是另外一套操作界面，功能包括商品分类管理（增删改查）、商品管理（上架、下架、修改库存、改价格）、订单管理（查看订单详情、修改订单状态）、用户管理（查看用户列表、禁用账号）。前后端分离之后，管理端和用户端其实是两个独立的前端项目，只是共用一个后端接口服务，这一点在前期就要想清楚目录结构怎么组织。
1.2 为什么说这个选题难度适中又不容易翻车
很多同学选题时的纠结在于：太简单怕老师觉得工作量不够，太难又怕自己搞不完。冷冻饮品甜品购物App这个题目属于典型的“业务有复杂度、技术有覆盖面、但天花板可控”的类型。
从业务层面讲，它比单纯的图书管理、新闻发布这类传统管理系统多了购物车、订单、库存、多角色权限这几个关键模块，工作量上有明显的增量。从技术层面讲，SSM覆盖了Spring的IOC和AOP、SpringMVC的请求处理流程、MyBatis的持久层映射，Vue覆盖了组件化开发、路由、状态管理、前后端交互，几乎把本科阶段JavaWeb的核心知识点全部串起来了。最关键的是，这个业务没有特别刁钻的算法和复杂的状态流转，订单状态无非就是待付款、待发货、待收货、已完成、已取消这几种，边界情况少，适合在有限时间内保质保量完成。
另外从答辩角度想，冷冻饮品和甜品这个商品品类有一个隐性的加分点：商品展示对图片、分类、价格梯度有天然需求，前端页面能做得好看到哪里去会直接影响第一印象。相比图书管理系统那种中规中矩的列表页，这种偏零售类的项目在视觉呈现上有更多发挥空间，而视觉呈现又是答辩时最容易让老师产生好感的部分。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型的底层逻辑与架构设计
2.1 SSM三件套的分工和它们各自的“为什么”
SSM是由Spring、SpringMVC、MyBatis三个框架组合而成的经典Java Web开发方案。很多同学会用框架但说不清框架之间到底怎么配合，我在这里用最朴素的话拆一遍。
Spring是整个系统的容器层，负责管理对象的创建和依赖关系。以前写Java Web要自己new对象、自己管理对象生命周期，类多了以后耦合得一塌糊涂。Spring用IOC（控制反转）把对象的创建权交给容器，你要用哪个Service，声明一下依赖，容器自动注入进来。AOP（面向切面编程）则用来做日志记录、事务管理等横切逻辑，比如下单这个方法必须开启事务，直接加一个@Transactional注解就行，不用在业务代码里手写begin和commit。
SpringMVC是Web层，负责接收HTTP请求、解析参数、调用Service、把结果返回给前端。它的核心流程是：前端请求先到DispatcherServlet，它根据URL找到对应的Controller方法，方法执行完后返回数据（通常转成JSON），再交给前端渲染。这一层回答了一个关键问题——“用户点了个按钮，后端怎么知道要执行哪段代码”。
MyBatis是持久层框架，负责Java对象和数据库记录之间的映射。以前用JDBC写数据库操作，每次都要写Connection、PreparedStatement、ResultSet那一大堆样板代码。MyBatis允许你把SQL语句写在Mapper XML文件里，只需要定义接口方法，SQL和参数映射都由框架搞定。在电商这种SQL比较灵活的场景下，MyBatis比Hibernate这类全自动ORM更直观、可控性更强。
这套组合在2026年的今天看来确实不算新，但对于毕设来说，老框架恰恰意味着生态成熟、问题容易搜到，而且SSM能让你在答辩时讲清楚Spring底层的Bean生命周期、代理机制这些细节。反过来说，如果直接用SpringBoot，虽然配置少了很多，但很多东西被自动配置“藏”起来了，老师几个追问下来你可能就露馅了。
2.2 数据库设计的核心表结构和字段规划
数据库设计是电商项目的骨架，表结构如果设计得不合理，后面写代码会处处被掣肘。这个项目我最终设计了七张核心表，这里把最关键的商品、订单相关表展开说。
用户表，字段包括主键id、用户名、密码（建议MD5加密存储或者用Spring的BCrypt）、昵称、手机号、头像URL、角色role（1表示用户，2表示管理员）、注册时间。需要注意用户名要做唯一索引，否则会出现重复注册的问题。
分类表字段相对简单，id、分类名称、排序值、创建时间。冷冻饮品和甜品这个项目里，分类可以拆成冰淇淋、冷冻饮料、甜品糕点、原料配料这几个，具体怎么拆取决于你准备录入哪些商品数据。
商品表是整个系统的核心，字段有id、分类id（外键关联分类表）、商品名称、商品描述、主图URL、轮播图URL、原价、现价、库存、销量、上下架状态、创建时间。这里有一个新手常犯的错误：把图片直接存到数据库里。正确做法是图片上传到服务器某个目录，数据库只存图片的访问路径，前端拿路径拼接出完整URL去加载图片。
购物车表字段是id、用户id、商品id、数量。它本质上是一个中间表，但要注意加一个联合唯一索引（user_id + product_id），防止同一用户把同一件商品加入购物车时产生重复记录。
订单表和订单明细表是电商系统里最重要的两张表，必须分开设计。订单表存的是订单维度的信息：id、订单编号、用户id、总金额、收货人姓名、收货人电话、收货地址、订单状态、下单时间、支付时间、发货时间。订单明细表存的是商品维度的快照：id、订单id、商品id、商品名称、商品图片、商品单价、购买数量。为什么明细表里要冗余商品名称和图片？因为商品可能会改价、改名甚至删除，但订单一旦生成，历史快照必须保留，这就是“快照”的意义。
收货地址表字段是id、用户id、收货人、电话、省市区、详细地址、是否默认地址。默认地址这个字段很关键，下单页需要回填默认地址来减少用户操作。
2.3 前端项目结构怎么组织才不容易乱
因为要做用户端和管理员端两套界面，前端目录我建议采用一个仓库两个子应用的方式。比如项目根目录下建portal（用户端H5）和admin（管理后台）两个文件夹，分别独立初始化Vue项目，它们共用同一个后端接口服务。
用户端选择Vue 2 + Vant 2的组合，或者Vue 3 + Vant 4的组合。我个人的建议是，如果学校教的还是Vue 2，那就用Vue 2，因为你对它更熟；如果对Vue 3的Composition API有信心，就用Vue 3。从技术趋势说Vue 3肯定是正解，但毕设的核心是“稳定跑通+答辩讲清”，用自己最熟的技术栈永远是对的。管理端用Vue + Element UI，表格、表单、弹窗这些后台管理组件拿过来直接用，效率会高很多。
用户端的页面结构大概是：首页（含分类导航和推荐商品）→ 分类页 → 商品列表页 → 商品详情页 → 购物车页 → 订单确认页 → 订单列表页 → 订单详情页 → 个人中心页 → 登录注册页 → 地址管理页。管理端的页面结构是：登录页 → 首页仪表盘 → 分类管理 → 商品管理 → 订单管理 → 用户管理。把这张页面地图先画出来，前端工作量和路由设计一下就清晰了。