基于Spring Boot与Vue的线上超市购物系统设计与实现

1. 项目全貌这套线上超市购物系统到底做了什么1.1 为什么选“线上超市”作为毕设题目先聊一个比较现实的话题Java方向的计算机毕业设计为什么“线上超市购物管理系统”这类题目经久不衰我自己的判断是三个字——太稳了。业务模型足够典型用户关系、商品、购物车、订单、库存这几张核心表一做基本覆盖了Java Web方向面试和答辩会问到的绝大多数高频点需求边界又足够清晰不存在那种“系统到底要做什么”都说不清的情况更重要的是同类项目沉淀了大量可参考的经验和踩坑记录你遇到的版本冲突、依赖缺失、端口占用前人基本都遇到过。这套题的完整名称是“基于SpringBoot的线上超市购物管理系统”从交付物的角度看它要求的不只是一堆能跑的代码而是完整的前后端代码加上说明文档和LW。这里的“LW”是毕设圈的叫法通常指开题报告、任务书、需求规格说明、数据库设计说明、测试报告这一整套材料。所以你在动手写代码之前就要先想清楚文档的结构代码模块和文档章节要对得上不然等到答辩前一周再去补文档就会发现代码和文档完全是两个世界那才是真的痛苦。这套系统最终落地的形态用大白话讲就是一个真实可用的B2C商城加一个后台管理端。用户可以在浏览器里浏览超市商品按分类筛选搜索商品名字把东西丢进购物车填写收货地址后下订单再模拟支付管理员则可以在后台维护商品上下架、调整库存、处理订单发货、管理用户和分类。前后端通过HTTP接口交互登录状态用Token管理数据库用MySQL缓存可以引Redis也可以不引主要看你希望把工程量控制在什么程度。1.2 用户和管理员的功能边界拆分功能之前我习惯先把“角色”这个概念定死。这套系统主要就是两种角色普通用户和系统管理员。两者的功能边界必须清晰否则代码写到最后全是权限混乱。角色核心功能典型接口/页面普通用户注册登录、商品浏览与搜索、加入购物车、结算下单、收货地址管理、订单查询、模拟支付/api/goods/list、/api/cart/add、/api/order/submit管理员商品上下架、库存管理、商品分类维护、订单审核与发货、用户管理、基础销售统计/api/admin/goods/save、/api/admin/order/page、/api/admin/stats功能面不需要铺得太宽一条主线就够了商品浏览→加购→下单→支付→管理员发货→订单完成。这条链路跑通以后再把注册登录、库存扣减、购物车数量限制这几个细节做扎实整个项目就已经超过了大多数停留在单表增删改查层面的毕业设计。这里特别提醒一个容易被忽视的点很多人把“管理系统”理解成管理端的CRUD但题目里面“购物”两个字才是真正的得分点。购物流程天然包含状态流转和事务比如订单从待支付、已支付、待发货、已发货到已完成任何一个状态变化都要有对应的触发入口还要拦截非法状态跳转比如已取消的订单就不能再去支付。如果能在代码里用状态机的方式把这条流转讲清楚答辩时这就是一个非常扎实的加分项。2. 技术选型拆解Spring Boot Vue这套组合赢在哪2.1 后端选Spring Boot是顺势但要清楚“自动装配”是什么Spring Boot走到今天基本就是Java Web项目的事实标准尤其在毕设场景里几乎是默认选项。它的核心价值不只是“开发快”而是把大量基础设施变成了约定内嵌Tomcat、自动装配、起步依赖、统一配置。pom.xml里引进一个spring-boot-starter-web一个main方法跑起来应用就能对外提供接口服务。对于只有一学期时间、还要兼顾文档和答辩的同学来说省去的是配置Web服务器和一堆XML的时间可以把精力放到真正的业务逻辑上。但有一个概念你必须能讲明白那就是“自动装配”。我见过太多同学嘴上说“项目用了Spring Boot”被问到spring-boot-autoconfigure是怎么知道该加载哪些Bean时却卡住。底层逻辑其实不复杂Spring Boot启动时会扫描META-INF/spring.factories文件里的EnableAutoConfiguration配置项然后根据classpath上是否存在对应的类来决定要不要执行某个自动配置。比如classpath下面有数据库驱动和spring-boot-starter-data-jpa它就自动配数据源和JPAclasspath里有Redis客户端它才去配RedisTemplate。这也是为什么你没引某个依赖却报找不到相关Bean时第一反应应该去看依赖是不是漏了而不是怀疑框架出问题。版本选择上如果不是特殊情况我建议用Spring Boot 2.7.x搭配JDK 1.8这套组合资料最多、最稳定。Spring Boot 3.x虽然新但包名从javax换到了jakarta很多老代码直接拷贝过来会编译报错拿来做毕设完全是给自己增加不必要的风险。2.2 前端Vue Element UI与“打包进SpringBoot”的部署方案前端这块毕设圈里的主流选择是Vue 2 Element UI或者Vue 3 Element Plus。后台管理页面的表格、表单、弹窗、树形控件Element这套组件库封装得最成熟几乎不用自己写样式。商城页面则可以用Vue写H5风格的商品卡片再配一个轮播图视觉上就有“网上超市”的感觉了。如果你以前没接触过前端框架也不用慌这种项目对前端的要求其实是“会用组件”而不是“会造组件”。常规开发路径就是用npm创建Vue工程装axios、vue-router、element-ui然后在views目录下建页面组件在api目录下封装请求函数最后用vue-router把页面串起来。真正需要花时间的是“前后端接口约定”比如后端统一返回{ code: 200, msg: ok, data: ... }这样的结构前端在axios拦截器里统一处理code这样联调阶段能少踩一半的坑。这里还有一个高频需求要重点说答辩演示的机器上不一定有Node环境所以“把Vue打包进SpringBoot”就成了非常实用的操作。做法分几步前端先执行npm run build把dist目录下的static目录和index.html拷贝到后端src/main/resources/static下面后端加一个Controller把根路径请求跳转到index.html再在WebMvcConfigurer配置类里放行静态资源映射。这样最终打出来就是一个jar一条java -jar命令跑起来页面和后端接口都在同一个端口演示时非常省事。注意如果用Vue的history模式路由刷新页面会出现404。两个解决办法要么改成hash模式要么在后端加一个转发规则把所有非/api开头的路径都转发到index.html。我建议直接选hash模式改动最小也最不容易出错。2.3 数据库设计核心表结构和几个关键避坑点数据表设计是评委会盯上的第一个东西也是最能暴露问题的地方。这套系统至少要有这几张表user表id、username、password用BCrypt加密后存储、real_name、phone、address、avatar、status。category表id、name、parent_id支持两级分类。goods表id、name、category_id、price、original_price、stock、sales、pic、detail、status。cart表id、user_id、goods_id、goods_name、price、num。order_master表id、order_sn、user_id、total_amount、status、pay_status、recv_name、recv_phone、recv_address、remark、create_time。order_item表id、order_id、goods_id、goods_name、price、num、total_price。订单为什么要拆主表和明细表因为一个订单可能包含多个商品如果只在主表里塞一个商品名称和价格就支持不了多商品订单。明细表里存goods_name和price是刻意做“快照”因为商品信息以后可能被改但订单一旦生成下单时的价格就必须固定这叫订单快照是电商系统的规范操作。字段设计上有几个坑要提前避。第一金额字段用decimal(10,2)不要用float或double浮点类型在计算金额时会出精度问题答辩的时候这也是个可以主动讲的点。第二库存字段用int就行别用double。第三每张表都加上create_time和update_time评委会问“表设计有没有考虑审计信息”到时候你有话可说。第四外键用逻辑外键就好不建物理外键因为实际业务系统里物理外键会影响扩展和迁移MyBatis-Plus体系下也不建议用它去维护关联关系。3. 核心链路实现从商品浏览到订单完成的完整闭环3.1 登录注册与JWT无状态认证登录注册不能只是“验证一下用户名密码”然后返回一个布尔值。我在这个项目里用的是JWT做无状态认证完整流程是这样的前端把用户名和密码传给后端后端用BCrypt校验密码通过后生成一个JWT Token返回前端把Token存到localStorage每次发请求时在axios拦截器里把Token塞进Authorization请求头后端用一个HandlerInterceptor拦截器统一校验Token解析出来的userId放到ThreadLocal里后续Controller直接取用不用每个接口再手动解Token。JWT的三个部分要能跟评委解释清楚。Header里是签名算法和Token类型Payload里放自定义数据一般放userId和过期时间expSignature由前两部分的Base64编码加上服务端密钥用HS256算法生成。Token的价值在于服务端不需要保存Session压力更小也方便做跨域和移动端扩展缺点是服务端没法主动把Token拉黑所以过期时间不能设太长我一般设2小时到24小时之间具体看项目要求。注册环节有两个细节。一个是密码一定要BCrypt加密绝对不要明文存数据库这是底线问题。另一个是用户名重复的校验要处理好如果MySQL的user表上建了unique索引重复插入会抛DuplicateKeyException你需要在全局异常处理器里捕获这个异常返回“用户名已存在”这样的友好提示否则用户看到的就是一串英文异常体验非常差。3.2 商品浏览、分类检索与分页查询商品列表页是用户进商城后看到的第一屏。后端提供一个GET /api/goods/list接口参数带pageNum、pageSize、categoryId、keyword、sort用MyBatis-Plus的Page对象做分页查询返回结果里带total前端再渲染分页组件。分页是我发现最容易写错的地方。很多同学前端传的是page和limit结果MyBatis-Plus的默认分页参数是current和size两边对不上就会出现“第一页正常第二页数据重复”这种诡异问题。规范做法是前端统一用pageNum/pageSize在Controller层转成MyBatis-Plus的current/size或者干脆定义后端自己的PageQuery对象让前端按这个结构传参。商品检索如果只是想按名字搜一个like查询就够了。希望效果好一点可以关联分类名称一起匹配再按销量或价格排序。这些SQL本身不难但要注意数据量小的时候看不出来性能差异答辩时被问到“数据量大了怎么办”你要能接上话——给goods表的name字段建普通索引必要时可以用Elasticsearch做全文检索。哪怕你只是了解这一层也必须把话说完不能愣在那里。3.3 购物车模块重复添加、价格快照和数量上限购物车的坑不在“能不能加”而在“加的时候发生了什么”。同一个用户往购物车加同一个商品大概率已经存在这时候应该把数量加1而不是新建一条记录。所以cart表要么给user_id和goods_id建联合唯一索引要么添加前先查一遍存在就更新数量不存在才插入。数量上限这个问题也经常被忽略。超市商品的库存可能只有50件购物车里却能写999这显然不合理。我建议在购物车接口和下单接口两层都做校验购物车里的数量不能超过库存下单时再校验一次库存并在事务里扣减。这样既保证了用户界面上的即时反馈也防止了后端并发下单导致的超卖。购物车里的price字段为什么要单独存因为用户加购时的价格是加入那一刻的价格。如果管理员后来改了商品价格购物车里的价格不应该跟着变否则就会出现“加购时50元结算时变57元”这种体验。所以购物车和订单明细都要存价格快照这是一个看着不起眼、但做和不做差距很大的设计。3.4 订单状态机与事务控制订单是这个系统的灵魂我建议用一个枚举类把状态定义清楚状态码含义允许的操作0待支付取消订单、去支付1已支付管理员发货2已发货确认收货 / 管理员标记送达3已完成无后续操作4已取消无状态机的价值在于避免“已取消的订单还能去支付”这类非法流转。实现方式不需要太复杂在OrderService里写一个changeOrderStatus(orderId, expectedStatus, targetStatus)方法更新SQL带上WHERE status expectedStatus如果受影响行数是0说明状态已经被别人改过直接抛业务异常。这个写法就是乐观锁的思想答辩时还能顺势串到“如何防止并发更新”这个话题上。下单接口是整个项目事务最复杂的地方校验收货信息、校验库存、生成订单号、插入主表和明细、扣减库存、清空购物车。这一串操作必须放在Transactional里任一环节失败都要整体回滚。订单号不要用自增id建议生成order_sn可以是时间戳加随机数也可以用雪花算法。雪花算法由时间戳、机器ID、序列号拼接趋势递增且全局唯一这句话讲出来答辩的深度就不一样了。4. 工程代码实操可直接复现的项目骨架4.1 后端五层结构与统一返回协议工程结构不能所有类堆在一个包下那是新手村的写法。我用的是五层结构controller、service、mapper、entity、common。Controller负责接收参数和返回数据Service负责业务逻辑和事务Mapper负责SQL和数据访问Entity映射数据表Common放统一返回结果、全局异常处理、工具类。答辩时你说“项目采用分层架构”它就不再是一句空话。统一返回结果类是这个项目的“交通规则”。我定义了一个Result类字段是code、msg、datacode为200表示成功500表示失败。注意HTTP状态码和业务code不一定相等。比如未登录场景HTTP状态是401但业务code可以设计成40100前端只认这个规则。这样设计的好处是后端抛业务异常时不需要每个Controller都写try-catch而是用RestControllerAdvice加ExceptionHandler做全局异常处理把BusinessException统一转成Result格式返回。4.2 关键代码片段Mapper扫描、订单号生成与全局异常核心Mapper其实没什么花活MyBatis-Plus的BaseMapper已经覆盖了大部分单表CRUD。真正有价值的是那些复杂SQL比如“近七天销售额统计”SELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM order_master WHERE status 1 AND create_time DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time)这类SQL建议写在XML里并且用Mapper注解标注Mapper接口。这里有个高频率的坑Spring Boot默认扫描不到Mapper接口报NoSuchBeanDefinitionException。解决办法是在启动类上加MapperScan(com.example.mapper)或者每个Mapper接口单独加Mapper。忘了加就会一直报“找不到Bean”我敢说每个Spring Boot开发者都踩过这个坑。订单号生成的简单示例public class OrderSnGenerator { public static String gen() { // 13位时间戳 4位随机数演示项目够用 return System.currentTimeMillis() String.format(%04d, new Random().nextInt(10000)); } }演示项目用这个没问题但并发情况下重复概率不是零。想做得更专业就回答“生产环境用雪花算法”然后把雪花算法的组成结构说清楚。4.3 前端接口封装与路由守卫前端工程按“页面-接口-组件”的思路组织。src下建views/user、views/admin、components、api、router几个目录。api目录下按业务域拆文件比如goods.js里放getGoodsList、addGoods、updateGoods、deleteGoods四个函数统一用下面这个格式import request from /utils/request export function getGoodsList(params) { return request({ url: /api/goods/list, method: get, params }) }request.js里用axios创建实例设置baseURL并在请求拦截器里加Tokenservice.interceptors.request.use(config { const token localStorage.getItem(token) if (token) config.headers[Authorization] Bearer token return config })响应拦截器统一处理业务code200时直接返回data401时跳登录页。这两个拦截器写好后每个页面就不用再单独处理错误码页面代码会非常干净。路由守卫是另一个容易漏的细节。用router.beforeEach判断页面是否要登录需要登录但没Token就跳登录页。管理端路由还要在meta里标记admin: true根据用户角色判断能不能进后台避免有人直接在地址栏拼 /admin/goods 就能闯入后台。这就是前端层面的访问控制。4.4 说明文档和LW的产出节奏文档一定要边做边写千万不要等代码全写完再补。常规文档清单是任务书、开题报告、需求分析、系统设计、数据库设计、系统实现、系统测试、总结致谢。整份文档要和项目代码对应上这句话听着像废话但每年都有同学被问到“文档里写的这个需求项目里怎么没做”时翻车。文档里至少要有三张图功能模块图、业务流程图、数据库ER图。功能模块图对应功能划分业务流程图对应“浏览商品→下单→支付→发货”的链路ER图对应表关系。这三张图画好整个项目逻辑就立体了。测试部分不用造假把真实跑过的用例写进去登录密码错误提示、重复添加购物车、库存不足下单被拦截、未登录访问订单页跳转、管理员越权访问被拒这些都可以复现写进测试报告没有任何压力。5. 实战记录从零运行这套项目的踩坑与排查5.1 环境配置三个高频问题先说我当时的运行环境JDK 1.8、Maven 3.6.3、MySQL 5.7、Node 14。这套组合最稳也是绝大多数毕设的底线环境。第一位的问题就是端口占用。Spring Boot默认8080被其他进程占满就会启动报错提示Port 8080 was already in use。处理顺序建议是先排查再改端口命令行执行netstat -ano | findstr 8080找到占用进程的PID然后任务管理器结束进程。如果这个端口是你故意要保留的再考虑改application.yml里的server.port但要记得同步改前端axios的baseURL否则请求就会打到错误端口上。第二是Maven依赖下载慢。国内访问中央仓库不稳定的时候在pom.xml里加阿里云镜像repositories repository idaliyun/id urlhttps://maven.aliyun.com/repository/public/url /repository /repositories第三是MySQL连接报错。java.sql.SQLException里绝大多数都是时区或SSL问题在JDBC连接URL后面加上serverTimezoneAsia/Shanghai和useSSLfalse基本能解决。这三个问题处理完项目就能从零启动起来了。5.2 前后端联调Bug定位三步法前后端分离项目最难的就是判断Bug到底出在哪一端。我自己的判断方法是一套三步走第一步看浏览器Network面板。请求有没有发出去状态码多少响应体是什么如果前端根本没发出请求多半是baseURL写错或者跨域被拦如果状态码404多半是后端路径跟前端不一致500才是真正的后端逻辑错误。第二步看后端控制台日志。Spring Boot启动时如果报NoSuchBeanDefinitionException多半是Mapper没被扫到或者Service没加Service注解。运行时的SQLException把SQL复制到数据库客户端里跑一遍基本立刻能分清是SQL本身的问题还是参数传参的问题。第三步看前端控制台。axios返回的err.response里就是后端标准错误信息把data.msg贴给后端比两个人在那里猜半天快得多。联调阶段我习惯在Controller里打印日志Log.info(receive param: {}, param)参数一进来就能看到这个习惯帮我节省了大量debug时间。5.3 答辩追问清单与库存并发保护做这个项目不只是交作业它还顺带覆盖了Java面试和答辩的好几个高频话题。我整理了一份追问清单建议每个人都提前准备追问方向考察点建议回答思路项目角色与难点项目陈述能力说自己负责后端核心模块最大难点是库存扣减和订单状态一致性JWT原理基础理论讲清三段式结构、无状态认证的优缺点事务注解失效场景Spring原理self调用导致代理失效、非public方法、try-catch吞掉异常库存超卖问题并发控制先说乐观锁再说分布式场景可以引入Redis预扣库存为什么前后端分离架构意识职责分离、独立部署、并行开发、扩展性好库存扣减单独展开一下。最直接的方案是乐观锁在goods表加version字段更新时SQL带上WHERE stock num AND version #{version}受影响行数为0就说明库存不够或数据被改了提示用户“库存不足”或做一次重试。更进阶的是数据库行锁SELECT ... FOR UPDATE把一行锁住再更新逻辑更硬但在程序里要对锁的释放时机非常小心。核心原则只有一条扣减库存和生成订单必须在同一个事务里绝不能先扣库存再单独写订单中间崩了库存就对不上账了。5.4 演示环境十分钟准备清单答辩现场最容易翻车的就是“demo环境当面起不来”。我建议正式答辩前至少完整跑通两遍“从零启动到演示完”的流程。顺手整理一份按顺序执行的清单第一步启动MySQL用数据库客户端执行初始化SQL脚本确认配置文件里的用户名密码和实际数据库一致。第二步启动后端IDEA里运行主类看到Started Application in X seconds字样表示成功。第三步启动前端。Node环境可用就npm install加npm run serve没有Node环境就走打包进jar的静态资源方案直接访问8080。第四步用预置账号登录一次确认管理员能进后台、普通用户能进商城。第五步演示时后端日志窗口放旁边讲到哪个模块就切到哪个页面实际操作一遍日志里对应打印清楚了比空口讲解有说服力得多。我这个项目做完最大的感受就是真正花时间的不是写代码本身而是把“为什么这么做”想清楚。库存为什么用乐观锁订单为什么要做状态机金额为什么用decimal价格为什么存快照每个设计决定背后都有实际业务逻辑在支撑。把这些想通了代码写起来反而特别顺答辩的时候也敢让评委随便往下追问。这个思路放到你手上任何一个毕设项目里都成立。