Spring Boot小型超市商品管理系统：毕业设计完整实战解析

1. 从毕业设计选题到落地：为什么我推荐这个项目

如果你是计算机相关专业的学生，大概率经历过这样的场景：选题表上列了一堆题目，要么是"基于XXX的XX系统"看着高大上，结果打开源码发现是个空壳；要么是需求描述模糊到根本不知道要做什么。而我今天要聊的这套Spring Boot小型超市商品管理系统，恰恰是那种看起来朴实无华、但实际涵盖面非常完整的典型毕业设计选题。

先说这个项目到底能干什么。它是一个标准的单体Web应用，面向小型超市的日常经营场景，核心解决三件事：商品信息集中管理、进货与销售的全流程跟踪、以及库存数据实时可查。作为毕业设计来说，它覆盖了需求分析、数据库设计、后端接口开发、前端页面联调、系统部署测试的全套流程，而且业务逻辑通俗易懂——每个同学都去过超市，不需要额外学习领域知识就能快速进入开发状态。

我为什么推荐这个方向？因为毕业设计的核心是"把一套完整的东西跑起来"，而不是追求技术多前沿。超市管理系统属于典型的CRUD密集型业务，但如果你往里加一点库存算法、一点报表统计、一点权限控制，它就不再是简单的增删改查，而是有业务深度、有技术含量的完整作品。更重要的是，这套系统的业务边界非常清晰，无论你做的是单机版还是前后端分离，都能自圆其说，答辩时不会被问倒。

这套系统适合谁来参考？第一类是正在准备毕业设计、需要完整源码和技术方案的同学；第二类是想学习Spring Boot实际项目结构、想知道"分开的各层到底怎么协作"的初学者；第三类是培训机构和老师用来当教学案例。你不需要是全栈高手，只要会Java基础、懂一点MySQL，就能把这套东西吃透并做出自己的改动。

在我看来，这个题目还有一个隐藏优势：它离现实生活足够近。超市是你每天都会接触的场所，这意味着你可以随时用实际场景来验证自己的设计是否合理——比如你去超市买东西时，可以观察收银台、货架标签、库存盘点这些真实业务，回来之后继续改进自己的系统设计。这种"从生活中来，到设计中去"的循环，恰恰是很多脱离实际的毕业设计题目很难提供的。

下面我按照自己实际做项目时的思路，从设计、拆解、实现、排错到答辩准备，帮你把这条链路彻底打通。

2. 整体设计思路拆解：先想清楚再动手写代码

2.1 用户角色与业务流程梳理

任何管理系统的设计，第一步都是搞清楚：谁在用这个系统，他们分别需要什么。超市商品管理系统也不例外，我把它抽象成三个角色：系统管理员、普通收银员、采购或仓管人员。很多同学做毕设时习惯只设计一个"管理员"角色，所有功能全部堆给一个人，这会导致系统内容单薄、答辩时缺乏亮点。我的建议是做三套权限，哪怕够用就行——管理员管用户和全局数据，收银员管销售开单，仓管管入库和供应商。这样至少能在答辩PPT里阳光地讲"权限分明的多角色协作"。

业务流程上，核心链路是"供应商进货→商品入库→货架销售→库存扣减→库存预警→补货建议"。围绕这条链，我把系统拆成了六大模块：商品管理、进货管理（采购入库）、销售管理、库存管理、供应商管理、系统管理（用户与权限）。每个模块还可以细分，比如销售管理里包含退货处理，库存管理里包含库存台账和预警阈值设置。

这里有一个设计上的关键点：进货和销售两个环节必须拆开，不能合并成一个"库存变动"记录。道理很简单，进货会提高库存成本，销售会影响利润核算，两者混在一起会让后续的统计报表变得混乱。我自己做过一个失败的版本，把进出库全放在一张流水表里，前期待着觉得方便，后来算利润、对账的时候才发现数据一塌糊涂，只能重构。千万别贪这个方便。

2.2 为什么选Spring Boot这套技术组合

技术选型上，Spring Boot + MyBatis Plus + MySQL + Vue（或Thymeleaf）是当前毕业设计的主流组合。选择它有几个非常实在的理由。

Spring Boot简化了Spring的复杂配置。以前用SSM框架时，光写xml配置文件就得耗一天，用Spring Boot之后大部分配置都自动装配，内嵌Tomcat一键启动，这对毕设党来说是极大的效率提升。MyBatis Plus比原生MyBatis更进步：单表操作不用写SQL，实体类加几个注解就能直接CRUD，分页、条件构造器开箱即用，内置逻辑删除、自动填充这些实用功能。MySQL则是稳字当头，大学课程里学的就是它，查资料也方便。

前端这一层，我推荐Vue 2 + Element UI。Vue的语法贴近正常逻辑，后端同学转前端首选的框架，Element UI的组件和表格风格很像是面向管理系统的，后端同学用起来很顺手。

有一点要提醒你：技术选型不要盲目追求新。比如现在Spring Boot 3已经发布，Java 17是它搭配的版本，可如果你平时练习用的是JDK 8，贸然上3.0会遇到很多兼容问题。毕业设计要的是稳稳交付，Spring Boot 2.7.x + JDK 8组合成熟、资料多，真出问题GitHub上随便一搜就有答案。

2.3 项目结构的划分之道

好的项目结构是让代码"看起来专业"的第一步。标准的Spring Boot项目用分层架构，我习惯分成这几层：Controller层负责接收请求、返回结果；Service层写业务逻辑；Mapper层负责数据库操作；实体类与数据库表对应；DTO/VO对象用于前端交互的数据传递。这样分层的好处是，出了问题知道去哪找，答辩时也能讲得头头是道。

我见过不少同学的代码，千行逻辑塞在Controller里，数据库操作直接写在接口层，导致改动一个功能就要把整个类翻一遍。这种代码对毕业设计来说其实是减分的。正确的做法是写一个商品查询接口时，Controller里只做参数校验和调用，具体的分页、条件拼装、数据组装放在Service里，Mapper只负责数据库的读写。虽然每个类都短小，但整体结构清晰，扩展和维护都舒服。

关于包命名，我习惯用com.example.supermarket作为基础包，下面再分为controller、service、mapper、entity、dto、config、common。其中common里放统一返回结果类、全局异常处理器、常量定义。你看了一眼就知道这个项目的层次，答辩时老师翻你的源码也能快速定位。

3. 系统核心功能拆解与数据库设计

3.1 实体关系与核心表设计

数据库是整个系统的根基。表设计好不好，直接决定后期开发是否顺畅。我这个项目设计了七张核心表：用户表、供应商表、商品表、进货单表、进货明细表、销售单表、销售明细表。另外加一张登录日志表，用于记录系统操作痕迹。

以商品表为例，我实际使用的字段结构如下：

CREATE TABLE `product` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '商品ID', `product_code` VARCHAR(32) NOT NULL COMMENT '商品条码或编号', `name` VARCHAR(100) NOT NULL COMMENT '商品名称', `category` VARCHAR(50) COMMENT '商品分类', `specification` VARCHAR(100) COMMENT '规格型号', `unit` VARCHAR(20) COMMENT '计量单位', `purchase_price` DECIMAL(10,2) COMMENT '进货价', `sale_price` DECIMAL(10,2) COMMENT '零售价', `stock_quantity` INT DEFAULT 0 COMMENT '当前库存量', `warning_threshold` INT DEFAULT 10 COMMENT '库存预警阈值', `supplier_id` BIGINT COMMENT '供应商ID', `status` TINYINT DEFAULT 1 COMMENT '状态：1在售，0下架', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有个容易忽略的细节：商品编码应该加上唯一索引，因为实际超市中每个商品有条码，系统内部也应该按唯一的编码管理，否则后期入库时会出现重复数据。我还专门加了库存预警阈值字段，注意它不是写死的，而是每个商品可以单独设置的。这样做的好处是大件商品或贵重商品可以设置更低的阈值，而快消品设置较高的预警值，贴合实际经营场景。

进货单表和销售单表的设计思路是一个主表对应一个明细表。主表记录本次单据的编号、操作人、时间、总金额，明细表记录每一件商品的数量、单价、小计。为什么这么做？因为业务上一张单据会包含多种商品，这是典型的一对多关系，如果不拆表，数据冗余会非常严重。以销售单为例，主表字段大致是：订单号、会员ID（如果有会员模块）、收银员ID、销售总金额、实付金额、折扣金额、创建时间。明细表则记录商品ID、销售单价、数量、小计金额。

3.2 后端接口设计清单

接口设计上，我遵循RESTful风格，把核心接口整理成一份清单，开发时照着列表写就行。这里列出一部分供参考：

在实际编码时，统一的返回结构非常重要。我自定义了一个Result类，包含code、message、data三个字段，所有Controller返回这个对象，前端拿到后统一判断code是否为200。这个习惯能省去好多联调的麻烦。

3.3 核心业务逻辑：库存扣减与状态联动

这个系统里最能体现"设计感"的地方，是销售单创建时的库存扣减逻辑。很多人会直接在Controller里写着"减掉库存然后保存订单"，但其实这里必须考虑事务管理的问题。

想象一个真实场景：收银员扫描了5件商品创建销售单，如果第3件商品扣库存成功，第4件商品库存不足报错，那么前两件的扣减要不要回滚？如果没有事务，就会出现数据不一致：订单没生成，库存却少了。我用@Transactional注解把整个"创建销售单+循环扣减库存"的过程包成一个事务，任何一步失败就整体回滚，保证数据一致性。这是最常见的面试题也是答辩时的得分点。

同时，库存扣减时我用的是"乐观锁"机制防止并发超卖。具体做法是在商品表加一个version字段，扣减库存时执行：

UPDATE product SET stock_quantity = stock_quantity - #{num}, version = version + 1 WHERE id = #{id} AND stock_quantity >= #{num}

这个SQL巧妙的点在于，它在数据库层面就完成了"查询判断+扣减"的操作，如果库存不够，影响行数为0，代码中据此抛异常回滚。你不用在读锁和写锁之间纠结，性能也不会受影响。

4. 技术选型的深层逻辑与关键配置

4.1 Spring Boot整合MyBatis Plus的正确姿势

如果用的是MyBatis Plus，依赖引入后有几个配置细节尤其值得注意。分页插件必须显式配置，否则分页功能直接无效。我见过最多的错误就是忘了配置MyBatis Plus的分页插件，导致page接口返回全部数据。正确配置是写一个配置类，注册PaginationInnerInterceptor。

逻辑删除也推荐开启。商品和供应商这种数据不建议物理删除——你删掉一个商品，历史销售记录里的商品名就关联不上了，统计报表直接出问题。MyBatis Plus的逻辑删除用起来很简单，实体字段加@TableLogic注解，配置全局逻辑删除值即可。这样执行delete操作时，实际执行的是update语句，把deleted字段置为1。

字段自动填充也是一个提高体验的小技巧。在createTime和updateTime上加上@TableField(fill = FieldFill.INSERT)和@TableField(fill = FieldFill.INSERT_UPDATE)，再实现MetaObjectHandler接口，就能在插入和更新时自动写入时间字段，省去在每个Service里手动set时间的重复劳动。

4.2 鉴权方案：JWT如何整合到Spring Boot

毕业设计如果做了登录功能，强烈建议用JWT而不是传统的Session。Session方案需要服务器保存会话状态，而JWT的本质是把用户信息放在一段签名的Token里，服务器不保存任何状态，天然适合前后端分离架构。

我的实现思路是：用户登录成功后，用JWT工具类生成一个有效期2小时的Token，返回给前端；前端把它存在本地存储里，并在每次请求的Header里带上Authorization字段；后端写一个拦截器，在请求进入Controller前解析Token，校验通过才放行，否则返回401错误码。

具体来说，JWT工具类里包含三个方法：生成Token、解析Token、校验Token是否过期。Token的payload部分我放了用户ID和用户名。注意要把密钥写长一点，至少32位，但不要硬编码在代码里，建议放在application.yml配置文件中，答辩的时候可以顺便讲讲"密钥管理"的考量。

4.3 前端页面与后端联调的工程化技巧

前端如果用Vue + Element UI，我会建议把Axios实例做一次统一封装。封装的作用在于：统一设置BaseURL，配置请求拦截器（每次请求自动带上Token），配置响应拦截器（统一处理后端返回的Result对象，code不为200时统一弹错误提示，HTTP 401时自动跳转登录页）。这个封装完成后，写业务页面时会感觉到异常方便——你只需关心数据本身，不用在每个页面里重复写错误处理代码。

页面开发时，我习惯先把后端接口调通，再填充UI细节。比如商品管理页面，先用Postman测试后端的增删改查接口，确认无误后再在Vue页面上把表格、表单、对话框这些组件绑定上。这种顺序能减少前后端同时出bug时互相甩锅的尴尬局面。

5. 实操过程：从零启动这个项目源码

5.1 下载源码后的目录结构与准备工作

拿到的这套源码，解压后通常会看到两个主要目录：backend和frontend。backend是Spring Boot工程，用Maven管理依赖，启动入口是SupermarketApplication类；frontend是Vue工程，如果用Vue CLI创建，目录里有package.json、src、public这些标准内容。

动手之前，先把环境检查一遍：JDK版本是否为1.8，Maven是否配置了阿里云镜像（否则下载依赖会慢到怀疑人生），MySQL版本是否为5.7或8.0，Node环境版本是否为14以上。这些是后续操作的硬前提，缺一个都会导致启动失败。

数据库初始化时，我建议用源码配套的SQL脚本执行一次完整导入，如果脚本包含测试数据，导入后你的系统里就会有一些可以马上操作的商品、供应商和用户记录。自己造测试数据是件费时费力的事情，有现成的直接导入能快速进入联调状态。

5.2 后端启动与常见启动错误处理

Spring Boot后端启动前，必须修改application.yml里的数据库账号密码，这一步谁也不能跳过，否则启动时会直接报数据库连接失败。改完配置后运行SupermarketApplication的main方法，观察控制台日志。

日志里出现"Started SupermarketApplication in xxx seconds"就代表启动成功，默认端口是8080，可以在浏览器访问Swagger文档地址（如果项目集成了）或直接访问Controller的接口测试。此时就可以用Postman测试登录接口，获取Token后访问商品分页接口，验证JWT拦截器的拦截效果和放行效果。

如果启动失败，优先检查这几个地方：MySQL服务是否启动；账号密码和application.yml是否完全一致；MySQL 8.0的驱动和时区配置是否正常。时区配置的坑我印象很深——连接串如果不加serverTimezone=Asia/Shanghai，启动直接报CST时区识别异常。

5.3 前端安装依赖与启动流程

后端跑通后，进入frontend目录，执行npm install安装依赖。这个过程视网络情况可能需要几分钟，如果卡住不动，大概率是网络问题，用npm镜像改一下registry地址就能解决。

依赖安装完成后，执行npm run serve启动开发服务器，默认端口为8080——这就会跟后端的8080端口冲突。解决方法是把前端开发服务器端口改成9528，在vue.config.js里设置devServer的port。前后端联调时，需要通过Vite或Webpack的代理配置把前端的axios请求转发到后端地址，否则浏览器会跨域。在vue.config.js中配置devServer.proxy，把'/api'前缀的请求都代理到http://localhost:8080。

浏览器访问前端地址，用初始账号登录，通常源码里会附一个admin/admin123的默认账号，成功登录后看到首页仪表盘，这套系统的骨架就已经完整地跑起来了。

5.4 做一个亮眼的改进：加入满减优惠功能

刚把项目跑通只是基础，毕业设计加分的关键在于做一些源码之外的改进。我建议加一个"满减优惠"功能：配置规则（满100减10、满200减25），销售单创建时自动计算最优优惠方案。这个改动表面上看只是多了一张优惠规则表，但它会牵动订单金额计算、库存扣减、利润统计三个环节，体现的是对业务逻辑的理解，而不只是会复制代码。

实现思路是在创建销售单的Service方法里增加一个步骤，根据销售总金额找到所有可用的满减规则，按优惠金额最大值匹配，然后计算实付金额。数据库设计优惠规则表，字段包括：规则名称、满减门槛金额、减免金额、启用状态。后续还可以加上满减的时间范围限制。这类只有一个核心功能的改动比较容易讲清楚，又比单纯抄CRUD更有说服力。

6. 常见问题速查与排错实录

6.1 启动类错误排查清单

我把实际踩过的坑整理成一张速查表，你在使用这套源码时如果卡住了，优先对照下面排查：

6.2 业务逻辑层面的边界情况

有一种情况在测试时经常出现：创建销售单时，商品库存刚好等于购买数量。此时正常流程应该扣减为0，然后系统自动将商品状态标记为"缺货"。如果代码里只做了减法而没有状态联动，就会出现库存为0但商品还在货架上显示有货的情况。

我的处理方式是在扣减库存的方法里增加库存判断逻辑：扣减后stock_quantity等于0时，把商品status字段更新为0（下架）。这样在前端页面上，商品自动从在售列表消失，同时在库存预警页面能看到"缺货"状态。反过来，进货入库操作时如果商品为下架状态，则自动更新为在售状态。这就是业务闭环，也是加分项。

批量操作也会暴露问题。在进货单里一次选了20个商品，其中1个商品不存在，是在前端就拦截还是在后端抛异常？我的建议是前端做好商品选择器的数据筛选，后端在保存前统一校验所有商品的状态和供应商一致性，发现任何一个异常就整体回滚，避免出现"半张单据"。

6.3 数据统计模块的SQL写法与细节

系统里最有含金量的功能，其实是"近7日销售趋势"和"热销商品Top10"这类统计功能。SQL写得好不好，直接影响答辩观感。以热销商品Top10为例：

SELECT p.name, SUM(si.quantity) AS total_quantity, SUM(si.subtotal) AS total_amount FROM sale_item si LEFT JOIN product p ON si.product_id = p.id WHERE si.create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY p.id ORDER BY total_quantity DESC LIMIT 10;

统计功能有个隐蔽的坑：行内求和SUM函数没问题，但如果销售明细关联了退货记录，统计退货数量时需要单独处理，不能直接从sales表里做减法。我建议在销售明细表中加一个order_type字段来区分正常销售和退货记录，统计时通过条件过滤。这样写出来的报表数据才经得起老师追问。

6.4 前后端跨域与联调难题

前端开发服务器是localhost:9528，后端是localhost:8080，两个不同端口必然存在跨域问题。如果前端通过代理转发，其实不会产生跨域问题，因为浏览器看到的是从同一个源发出去的请求。如果前端直接请求后端地址，则需要在后端配置跨域过滤器。

我通常直接用前端代理的方式解决。配置好后，前端代码里所有的请求路径都只写/api/xxx，不需要写完整的后端地址。这样做的好处是，将来部署时只需要改代理配置，不用修改任何业务代码。

除了跨域，字段命名不一致也是联调中经常出现的问题。后端返回的字段名通常是驼峰命名（如stockQuantity），前端如果直接用下划线字段（stock_quantity）会取不到值。用MyBatis Plus时设置了map-underscore-to-camel-case=true后，数据库字段自动映射为驼峰属性，所以接口返回的JSON自然就是驼峰。这个属性默认开启，但如果自己手写了XML查询，建议检查返回数据的代码里是否保持了相同的命名风格。

7. 论文写作与答辩准备的思路参考

7.1 需求分析的写法：从场景出发

毕业设计论文的需求分析章节，很多人写成了功能列表流水账，这是答辩被老师挑剔的重灾区。正确的写作方式是从实际场景引入痛点，再推导出功能需求。

比如你可以这样写："通过观察小型超市的实际经营场景，发现存在商品信息查询效率低、库存盘点依赖人工、进货与销售数据易错等问题，因此本系统需要实现商品信息的集中管理、进货销售的流程化记录、库存数量的自动更新与预警提醒等功能"。把这几个需求设计出来，论文的逻辑链就完整了。

7.2 答辩时的典型提问与思路

答辩环节，老师通常不会先看代码，而是会先问"你这个系统解决了什么问题"和"为什么用这个技术"。回答时要突出业务理解和技术选型的理由。

问到"为什么用Spring Boot"时，不要只回答"因为它简化配置"，要补充"它通过自动配置和起步依赖降低了项目搭建成本，内嵌Web容器让部署更便捷"这类具体层面的解释。问到"库存扣减怎么防止超卖"时，把前面提到的乐观锁SQL说出来，再加上事务保证一致性，就已经是标准回答。

还有一类高频问题："如果订单量变大，会不会性能不足？"这种问题不用慌，回答逻辑是先承认单体架构的局限，然后说"当前系统面向小型超市规模，单机性能足够；未来如果业务增长，可以通过缓存、读写分离、异步消息等方式进行扩展"。这个回答显得有思考深度，又不会给自己挖坑。

8. 写在最后的一点真实体会

这套Spring Boot小型超市商品管理系统做下来，给我最大的感触是：毕业设计本身并不难，难的是选择一个能控制住复杂度、又能完整展现开发能力的方向。超市管理系统就是这样一个恰到好处的选题——业务容易理解，技术覆盖全面，无论你未来是不是做Java开发，整套流程做下来，你对"一个软件是怎么从需求变成代码"都会有比课堂上清晰得多的认识。

如果你想在这套源码的基础上做出差异化，我的建议是不要贪多，选择一个点做深。比如你可以把库存预警做成更智能的模式——根据最近一段时间的销售速度动态计算补货建议；也可以把统计报表加上图形化展示——用ECharts画销售趋势折线图和品类占比饼图；甚至可以在前端引入Excel导入导出功能，把商品批量录入这个真实存在的需求解决掉。一个亮点就够了，把它讲透，比加十个半成品功能都管用。

最后再分享一个小技巧：如果你打算用这套项目参加答辩，提前在演示环境里准备一批真实感很强的测试数据。比如"农夫山泉550ml"、"可口可乐330ml"、"伊利纯牛奶250ml"这种大众熟悉的名字，配上合理的进价和售价。演示时用这些数据操作一遍收银流程，再打开库存预警页面，老师一眼就能看懂整个系统在干什么。这种细节带来的好感，比你答辩时背十页PPT都有用。