基于SpringBoot+Vue的超市管理系统毕业设计实现指南

很多计算机专业的学生在做毕业设计时，都会面临同一个灵魂拷问：到底选一个什么题目，才能既保证工作量、又能顺利通过答辩，最好还能在写进简历时显得不那么“水”？

超市管理系统，恰好就是这样一个“看起来烂大街，但真正做好的人并不多”的经典选题。每年都有大量学生选这个方向，但不少人交上去的作品只是一张商品表加一个增删改查页面，答辩时老师随口问一句“销售出库时库存扣减怎么保证不出错”，就直接卡壳。这篇文章我会从毕业设计实际落地的角度，把一个基于 SpringBoot + Vue 的超市销售管理系统拆开来讲明白：从选题价值、功能设计、数据库表结构，到后端登录鉴权、商品管理、销售出库事务处理，再到前端联调和部署上线的完整思路。如果你正在准备 Java 方向的毕业设计，或者打算用 SpringBoot 做大作业、课程项目，这篇文章可以作为一份完整的参考路线。

1. 为什么“烂大街”的超市管理系统，反而是稳妥又聪明的选题

先给一个判断：超市管理系统不是最好的选题，但一定是最稳的选题之一。原因在于它所覆盖的技术栈非常均衡，一套系统里既有基础的数据建模，又有业务逻辑中的事务、权限、状态流转，还有前端交互和联调，难度梯度刚好卡在“努力一下能够到”的位置。

很多同学一开始想选一些听起来炫酷的选题，比如“基于深度学习的商品识别系统”“基于区块链的供应链溯源平台”。做这些题目的风险其实很高：一是数据来源不好找，二是算法或底层框架的坑多到自己填不完，三是答辩时老师问几个原理性问题，如果理解不够深入，反而比做一个朴素但扎实的 CRUD 系统更容易翻车。

超市管理系统的业务边界非常清楚，核心就三件事：管商品、管库存、管销售。围绕这三件事，还能自然延伸出供应商管理、进货入库、销售出库、退换货、统计报表、用户权限等模块。每一块都有明确的现实对应场景，老师不需要额外追问业务合理性，你自己也非常容易解释清楚“为什么需要这张表”“为什么这里要加一个状态字段”。

更关键的是，这套系统完成后，技术迁移能力很强。你做懂了超市的商品和库存管理，改一改字段就能变成奶茶店点单系统、服装店进销存系统、校园超市管理系统，换个业务皮就能形成不同风格的毕业设计题目。这也是为什么每年都会有人把类似的系统翻来覆去地做，但依然能拿到不错成绩的原因——重点不在于题目多新鲜，而在于你对业务细节和技术方案的理解是否到位。

当然，这里也要泼一盆冷水。正因为这个选题太常见，如果你只是把网上某个开源项目原封不动下载下来，改个标题提交上去，结果大概率不是高分，而是查重直接翻车。真正聪明的做法是把它当成一份半成品模板，在理解每一条代码路径之后，加入自己的思考和改进点，做出“你的版本”。

2. 系统总体设计：角色、功能模块与核心业务流程

一个完整的超市管理系统通常包含两种角色：系统管理员和收银员或普通员工。管理员负责后台维护工作，收银员负责日常销售操作。角色不同，看到的页面和可以使用的能力也不同。下面是一个典型的模块划分。

这里有一个很多课设容易做错的设计点：不要把销售记录直接写成“修改商品表里的库存数量”这样一个动作，而是要在创建销售单时，同时写入销售主表、销售明细表，并更新库存表。这三者必须在一个事务中完成，任何一步失败都要整体回滚。这个设计直接关系到“数据一致性”，也是答辩时老师最喜欢追问的点。

从业务流程上看，一个商品的完整生命周期是：管理员先录入供应商信息，再录入或导入商品信息，然后通过进货入库功能给对应商品增加库存。顾客购买时，收银员在销售页面选择商品、确认数量、结算，系统扣减库存并生成销售单。库存低于预警阈值后，系统提示补货，管理员再走一次进货入库。整个闭环非常清晰，也方便后期扩展会员、促销等功能。

从开发顺序来看，建议按照“用户登录 → 员工管理 → 商品分类 → 商品管理 → 供应商管理 → 进货入库 → 销售出库 → 库存查询 → 统计报表”的顺序推进。前几个模块本质上是基础 CRUD，用来熟悉项目结构；到进货入库和销售出库，再引入事务和状态流转的复杂度；统计报表则是对前面数据的聚合查询。

3. 技术选型：为什么是 SpringBoot + Vue 的前后端分离方案

近年来 Java 方向的毕业设计，前后端分离方案已经逐渐成为主流。核心原因很实际：企业里真正在用的新项目，几乎都是这个架构。你要在简历里写“熟悉前后端分离开发”，就必须真正独立完成过一次前后端联调。而 SpringBoot + Vue 是这个技术栈里生态最完善、资料最多、遇到问题最好搜到答案的组合。

技术栈可以按下面这套配置准备：

这里需要补充一个版本上的重要提醒：Spring Boot 3.x 要求 JDK 17 及以上，而 Spring Boot 2.7.x 使用 JDK 8 就可以。如果你下载到的参考资料锁定了 Spring Boot 2.x，就老老实实用 JDK 8，不要强行升级到 JDK 17；如果项目是 Spring Boot 3.x，则必须使用 JDK 17。版本不一致导致的启动失败，是每年毕设季出现频率最高的环境问题之一。

很多教材里还会教 JSP + Servlet 或 SSM 三大框架，这类方案现在不是不能用，而是工程效率偏低：没有自动配置，所有 Bean 都要在 XML 里手动声明，前端页面使用 JSP 也无法做到前后端分离。对于课设和毕设来说，SpringBoot + Vue 已经是风险最低的选择，因为它的参考资料数量级远大于其他方案。

MyBatis Plus 的地位也需要明确：它不是 MyBatis 的替代品，而是增强工具。它的内置方法可以帮你省掉单表 CRUD 的大量 XML 映射，但复杂的多表联查仍然需要自己写 SQL。在简历上写“熟练使用 MyBatis Plus”是可以的，但前提是你清楚它底层生成 SQL 的规则，以及自定义 SQL 写在哪个目录。

4. 数据库设计：超市管理系统的核心表结构

数据库设计是毕业设计中最能拉开差距的部分。很多低分作品只有三四张表，把所有信息都堆在一起；而一个合理的超市管理系统，至少要包含员工表、商品分类表、商品表、供应商表、进货单主表、进货单明细表、销售单主表、销售单明细表和库存表。下面给出核心表的简化设计思路。

-- 用户表 CREATE TABLE `sys_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT 'BCrypt 加密后的密码', `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名', `role` varchar(20) NOT NULL DEFAULT 'EMPLOYEE' COMMENT '角色：ADMIN/EMPLOYEE', `status` tinyint NOT NULL DEFAULT '1' COMMENT '1启用 0禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

用户表的核心点在于：密码不能明文存储，必须使用 BCrypt 加密；角色字段决定了前端菜单的展示和后端接口的访问权限。

-- 商品表 CREATE TABLE `goods` ( `id` bigint NOT NULL AUTO_INCREMENT, `barcode` varchar(50) DEFAULT NULL COMMENT '商品条码', `name` varchar(100) NOT NULL COMMENT '商品名称', `category_id` bigint DEFAULT NULL COMMENT '分类ID', `spec` varchar(50) DEFAULT NULL COMMENT '规格，如 500ml/瓶', `unit` varchar(10) DEFAULT NULL COMMENT '单位，如 瓶/盒', `purchase_price` decimal(10,2) NOT NULL COMMENT '进货价', `sale_price` decimal(10,2) NOT NULL COMMENT '零售价', `stock_warn` int DEFAULT '10' COMMENT '库存预警阈值', `status` tinyint DEFAULT '1' COMMENT '1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

商品表需要注意两个字段：规格和单位。很多初学者会忽略它们，但超市场景下同一商品可能有多种规格，比如同一款饮料有 500ml 和 1L 两个规格，如果不区分，销售时就会算错库存。

-- 销售单主表 CREATE TABLE `sales_order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '销售单号', `cashier_id` bigint NOT NULL COMMENT '收银员ID', `total_amount` decimal(10,2) NOT NULL COMMENT '应收总金额', `pay_type` varchar(20) DEFAULT 'CASH' COMMENT '支付方式', `sale_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 销售明细表 CREATE TABLE `sales_order_item` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_id` bigint NOT NULL COMMENT '销售单ID', `goods_id` bigint NOT NULL COMMENT '商品ID', `goods_name` varchar(100) DEFAULT NULL COMMENT '商品名称快照', `sale_price` decimal(10,2) NOT NULL COMMENT '销售单价快照', `quantity` int NOT NULL COMMENT '数量', `sub_total` decimal(10,2) NOT NULL COMMENT '小计' PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

销售单拆成主表和明细表，是标准的“一主多从”设计。主表存一次销售的整体信息，明细表存每一件商品的快照。之所以要把商品名称和销售单价冗余到明细表中，是为了防止日后修改商品表导致历史订单数据失真。这个小细节，是很多教材项目里没有处理好的地方。

库存表可以直接使用商品表中的一个字段 store_quantity 表示，也可以单独建一张 stock 表。对毕设而言，直接在商品表加一个库存字段是最简单的方案；但如果你想要差异化，可以考虑单独建库存表并支持多批次入库，这会显著增加答辩时可讲的内容量。

5. 后端核心代码实现：认证、商品管理与销售出库

5.1 登录认证与 JWT 拦截器

前后端分离项目里，通常不使用传统的 Session。更常见的是登录成功后后端返回一个 Token，前端每次请求时把它放在请求头里，后端通过拦截器解析 Token 确认用户身份。这里用最简单的方式演示思路：引入 JJWT 依赖，写一个工具类生成和解析 Token。

// 文件路径：src/main/java/com/supermarket/common/utils/JwtUtil.java public class JwtUtil { private static final String SECRET = "supermarket-demo-secret-key"; public static String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

真正使用时，还需要写一个拦截器，在进入到 Controller 之前检查请求头中的 Token。如果没有 Token 或 Token 解析失败，直接返回 401。这个拦截器可以通过WebMvcConfigurer注册，并设置放行登录接口、静态资源等路径。

认证逻辑里容易被忽略的一个点是密码校验。用户提交的明文密码不能直接与数据库中的密码比较，而是应该使用BCryptPasswordEncoder.matches(rawPassword, encodedPassword)方法校验。这样即使数据库泄露，用户的密码也无法被直接还原。

5.2 商品管理接口

使用 MyBatis Plus 时，最简单的 CRUD 甚至可以不写 SQL。下面是一个典型的 Service 实现，演示了分页查询商品列表并关联分类名称的思路。

// 文件路径：src/main/java/com/supermarket/service/impl/GoodsServiceImpl.java @Service public class GoodsServiceImpl extends ServiceImpl<GoodsMapper, Goods> implements GoodsService { @Override public PageResult<GoodsVO> pageGoods(GoodsQuery query) { Page<Goods> page = new Page<>(query.getPageNum(), query.getPageSize()); LambdaQueryWrapper<Goods> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(query.getName()), Goods::getName, query.getName()) .eq(query.getCategoryId() != null, Goods::getCategoryId, query.getCategoryId()) .orderByDesc(Goods::getCreateTime); Page<Goods> result = this.page(page, wrapper); // 这里需要手动填充分类名称，通常是在循环中查询分类表或提前批量查询 return PageResult.from(result); } }

这里需要强调的是 LambdaQueryWrapper 的写法。like、eq的第一个参数是 boolean 条件，第二个参数才是字段和值，这样当查询条件为空时，这条条件会被自动跳过。很多第一次接触 MyBatis Plus 的同学会漏写判断，导致传入空值时 SQL 自动拼接and name like '%%'，结果虽然不影响正确性，但会多一次不必要的查询。

商品新增或修改时，建议做字段校验：商品名称不能为空、售价必须大于等于 0、进货价不能为负数。这些校验可以放在 Controller 层，也可以使用 Spring 的@Validated注解配合实体类上的校验注解，后一种方案更简洁，也更能体现工程素养。

5.3 销售出库：事务与行锁

销售出库是整个系统中技术含量最高的部分。它的业务逻辑是：创建销售主单、逐条扣减库存、计算总金额。由于库存扣减不能“凭空减少”，比如库存只有 5 件却售出 10 件，此时必须抛出异常并让整笔销售回滚。下面是核心代码。

// 文件路径：src/main/java/com/supermarket/service/impl/SalesOrderServiceImpl.java @Service public class SalesOrderServiceImpl extends ServiceImpl<SalesOrderMapper, SalesOrder> implements SalesOrderService { @Resource private GoodsMapper goodsMapper; @Override @Transactional(rollbackFor = Exception.class) public SalesOrder createOrder(SalesOrderCreateDTO dto) { // 1. 创建销售单主记录 SalesOrder order = new SalesOrder(); order.setOrderNo(OrderNoGenerator.generate()); order.setCashierId(dto.getCashierId()); order.setPayType(dto.getPayType()); order.setTotalAmount(BigDecimal.ZERO); this.save(order); BigDecimal total = BigDecimal.ZERO; // 2. 遍历销售明细 for (OrderItemDTO item : dto.getItems()) { // 2.1 查询商品最新信息 Goods goods = goodsMapper.selectById(item.getGoodsId()); if (goods == null) { throw new BusinessException("商品不存在：" + item.getGoodsId()); } // 2.2 条件更新库存：防止并发超卖 int rows = goodsMapper.deductStock(item.getGoodsId(), item.getQuantity()); if (rows == 0) { throw new BusinessException("商品[" + goods.getName() + "]库存不足"); } // 2.3 生成明细记录，商品名称和价格做快照 SalesOrderItem orderItem = new SalesOrderItem(); orderItem.setOrderId(order.getId()); orderItem.setGoodsId(goods.getId()); orderItem.setGoodsName(goods.getName()); orderItem.setSalePrice(goods.getSalePrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubTotal(goods.getSalePrice() .multiply(BigDecimal.valueOf(item.getQuantity()))); salesOrderItemService.save(orderItem); total = total.add(orderItem.getSubTotal()); } // 3. 更新主单总金额 order.setTotalAmount(total); this.updateById(order); return order; } }

对应的 Mapper 中需要写一个自定义的扣减库存 SQL：

<!-- 文件路径：src/main/resources/mapper/GoodsMapper.xml --> <update id="deductStock"> UPDATE goods SET store_quantity = store_quantity - #{quantity} WHERE id = #{goodsId} AND store_quantity &gt;= #{quantity} </update>

这个写法的精华在于where store_quantity >= #{quantity}。两个并发请求同时来扣库存时，数据库的行锁会保证只有一个事务能成功更新；第二个事务执行后会发现影响行数为 0，从而判断库存不足并抛出异常。很多教程里会先 select 查库存数量，在 Java 代码里 if 判断库存是否充足，再 update，这种做法在单机低并发演示时没问题，但在并发场景下会出现严重 bug，答辩时被问“超卖怎么解决”时一定要能说出这两者的区别。

另外@Transactional(rollbackFor = Exception.class)这个属性也不能忽略。Spring 默认只在遇到运行时异常时回滚，如果方法抛的是自定义的 checked exception，不加 rollbackFor 是不会触发回滚的。这是很多网上代码容易踩的坑。

6. 前端页面开发与前后端联调

如果你使用的是 Vue + Element UI 这样的成熟管理后台方案，前端的核心工作量其实集中在三个方面：登录页与 Token 存储、axios 请求封装、业务页面表单和表格。

登录成功后，前端需要把 Token 保存起来，常见做法是放入 localStorage。然后 axios 请求拦截器统一从 localStorage 读取 Token 并拼接到请求头。

// 文件路径：src/utils/request.js import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { Message.error('登录已过期，请重新登录') localStorage.removeItem('token') router.push('/login') } else { Message.error(error.message || '网络异常') } return Promise.reject(error) } ) export default request

这里把 axios 实例化后暴露出来，业务页面里通过request.get('/goods/page')这类方式调用接口。统一封装的好处是：接口返回结构的变化只需要在一个文件里调整，请求头、异常处理也都在同一处维护。这个习惯非常好，也是工作之后依然会使用的模式。

前端页面开发时，如果后端还没完成，可以先用 mock 数据把页面调通；后端接口写好后再把请求地址切换到真实地址。前后端联调时出现概率最高的一类问题是跨域。开发环境一般通过 Vue CLI 的 proxy 配置解决，生产环境则使用 Nginx 反向代理。最佳实践是前后端约定统一的接口前缀，比如/api，所有接口都挂在同一个前端域名下，这样跨域问题可以收敛到代理层处理，而不是在业务代码里到处配置 CORS。

7. 本地运行与服务器部署

完成开发后，项目需要能在自己电脑上跑起来，这是毕业设计检查和答辩演示的基本要求。本地运行的大致步骤如下。

本地启动后端：

# 1. 导入数据库脚本 mysql -u root -p < supermarket.sql # 2. 修改 application.yml 中的数据库连接信息 # 3. 启动后端 mvn spring-boot:run

本地启动前端：

# 1. 安装依赖 npm install # 2. 开发模式启动 npm run serve

如果后端端口是 8080，前端 Vue CLI 开发模式端口是 8081，需要在vue.config.js中配置代理，将/api开头的请求转发到 8080 端口。

部署到服务器时，一套常见的方案是：后端打包为 jar，使用nohup java -jar启动；前端执行npm run build生成 dist 目录，然后用 Nginx 托管。如果需要配置域名和 HTTPS，还需要申请证书，但毕设阶段使用 IP 加端口访问也可以接受。

这里要特别提醒安全相关的问题：不要在服务器上使用 root 用户直接运行 Java 应用；数据库不要使用 root 账号作为业务连接账号；服务器防火墙只放行必要端口；打包前把配置文件中的数据库密码改成强密码。这些属于生产环境的基础安全卫生，做到位之后不仅系统更安全，写进文档里也是加分项。

8. 常见问题与排查思路

排查问题的顺序非常重要。最忌讳的做法是一上来就怀疑代码逻辑，结果改了半天发现是数据库版本问题。正确顺序是：先看控制台和浏览器 Network 面板，把报错信息定位到具体层次；再检查环境配置，最后检查代码逻辑。定位问题范围的能力，比解决问题本身更影响开发效率。

9. 毕业设计答辩高频问题与差异化改进方向

答辩时老师通常不会问太多具体的业务细节，而是更关注“你自己做的东西，你是不是真懂了”。下面这组问题出现的频率很高，建议提前准备好回答思路。

SpringBoot 相比传统 SSM 框架简化了什么？自动配置和约定优于配置是核心。比如内嵌 Tomcat、自动装配数据源、starter 机制减少依赖坐标书写，这些都是可以在简历里明确写出的亮点。

为什么使用前后端分离？前后端分离后，后端只提供 JSON 接口，前端负责页面渲染，两者可以独立开发测试；部署时前端用 Nginx，后端独立进程，扩展和维护更清晰。不要只答“很多人这样做”，要讲清楚工程上的收益。

销售出库时如何保证库存不超卖？使用条件更新 SQL，扣减库存时加上where store_quantity >= quantity条件，配合事务保证整体原子性。这个答案如果在答辩时能自己说出来，老师会明显认可。

密码存储为什么不直接使用明文？因为数据库可能泄露，明文密码会让用户在其他平台的账号也处于风险中。BCrypt 加密是单向不可逆的，并且自带盐值，是当前普遍推荐的方案。

如果想让系统更有记忆点，可以从以下几个方向挑选一两个做扩展：引入会员表和积分功能，让销售模块与会员模块产生业务联动；使用 ECharts 做商品销量趋势图和管理员驾驶舱；加入 Redis 缓存商品热榜，体现中间件使用能力；将商品导入导出做成 Excel 文件操作，补充报表能力；更进阶一点，可以加入多门店字段，让系统支持门店维度数据隔离。

需要控制的是一件事：不要同时新增太多扩展功能。毕业设计的核心是“闭环”和“可靠性”，不是功能数量。与其做五个半成品模块，不如把一个核心模块做得干净、严谨、经得起追问。

10. 拿到参考源码后，怎么把它变成你自己的项目

市面上能够下载到的基于 SpringBoot 的超市管理系统源码非常多，但绝大多数存在同样的问题：能跑通，但缺少质量层次感。正确使用这些参考资料的方式，可以按照下面几步来做。

第一步，把项目跑起来，理解目录结构。SpringBoot 项目的 controller、service、mapper、entity、config、common 这些包分别做什么，要在半天之内理清。这一步完成之前，不要急着改任何代码。

第二步，从登录模块开始追一遍完整链路。前端登录页面提交用户名密码，后端 Controller 接收，Service 校验，JWT生成，前端保存 Token，后续请求携带 Token，拦截器解析——完整走一遍后，你才算真正理解了这个项目的第一条主链路。

第三步，选择一个核心业务模块进行重构或二次开发。比如把销售模块从简单的“更新商品库存”改成“主表明细 + 事务 + 条件更新库存”，把库存管理从无脑 CRUD 改成带预警阈值的查询。这样做出来之后，代码和原始项目已经不同，答辩时也能自信地说出为什么这样设计。

第四步，写文档时不要照抄别人项目里的设计说明。可以保持同样的章节结构——需求分析、系统设计、数据库设计、核心功能实现、测试——但每一个部分都应该基于你自己最终实现的代码来写，插入你自己的表结构和核心代码截图。

第五步，提前把检查可能遇到的问题准备成问题清单，尤其是库存扣减、事务回滚、Token 过期、打包部署这几类。

总的来说，超市管理系统是一个非常成熟的毕设选题，上限和下限都很明确。下限是一张商品表加一个增删改查页面，三个月做完仍然没有亮点；上限则是数据建模合理、核心业务事务严谨、前后端联调顺畅、能够讲清楚每一次技术决策的理由。如果你正在准备这个题目，希望这篇文章能帮你规划出一个更有把握、也更有技术含量的版本。下一步的建议是：把数据库建起来，先把用户登录跑通，再往里面一步步填模块。代码不是看会的，是跑出来、改出来的。