做了几个学期的辅助指导之后我越发觉得一件事是真的很多同学毕业设计做得辛苦其实不是不会写代码而是根本不知道一个项目该从哪里下手。拿这次要说的网上超市系统来说SpringBoot Vue MySQL这套组合几乎每个计算机专业学生都听过但把它真正落地成一个能演示、能答辩、能写进论文的完整项目涉及到的细节远比想象中多。这篇文章我想换个讲法不给你们贴那种书本式的教程而是把这个项目从选型到部署、从代码到论文的全过程拆开聊。所有内容包括项目正文、源码、数据库脚本、论文框架和部署文档都是围绕一个完整的网上超市系统展开。无论你是打算照着做一遍还是想理解每个模块为什么这么设计这篇文章应该都能给你提供一个清晰的地图。1. 为什么说SpringBoot Vue MySQL是毕业设计的安全牌每年到毕业季我都会收到一批私信问的大同小异老师要求做一个管理系统到底用什么技术栈比较稳我的回答通常只有一个SpringBoot Vue MySQL。这套组合看起来没什么花样但恰恰因为没花样它的确定性最高。1.1 从技术选型的底层逻辑聊起先说后端。SpringBoot之所以成为主流核心在于它把配置简化到了极致。过去用SSMSpring SpringMVC MyBatis写项目光是xml配置就能折腾一个星期而SpringBoot通过自动化配置把这些繁杂的东西全部接管了。你在项目中引入一个依赖它就能自动帮你装配好对应的Bean你只需要专注写业务逻辑。对毕业设计来说这意味着你不需要把时间浪费在环境搭建上而是能把精力放在更重要的业务实现上。Vue这边更是如此。以前的前端开发是拿着jQuery在DOM上做手术页面一复杂代码就乱了。Vue的响应式数据绑定和组件化开发让你可以把一个页面拆成若干个独立的组件每个组件只管自己的数据和行为。比如网上超市系统里的购物车、商品列表、订单详情各自都是一个组件互不干扰调试起来非常清爽。MySQL作为数据库在毕业设计这个量级上性能绰绰有余。有些同学一上来就想整MySQL Cluster或者读写分离我的建议是除非你论文里的创新点就是这个否则完全没必要。单机MySQL加合理的事务处理足以支撑一个中小型网上超市场景的演示和测试。1.2 前后端分离到底分在了哪里选了这个技术栈就必须理解前后端分离这个架构概念。毕业设计答辩时老师几乎必问这个问题。前后端分离本质上是把用户的交互逻辑和业务数据处理逻辑拆到两个独立运行的进程中。前端Vue项目运行在Node环境里通过HTTP请求访问后端SpringBoot项目提供的RESTful接口后端SpringBoot项目负责从MySQL读写数据处理业务规则再把结果以JSON格式返回给前端。这样做的好处有三个第一前后端可以并行开发前端不用等后端接口写完就能用Mock数据先行渲染页面第二职责清晰前端的bug不会拖垮后端服务反过来也一样第三扩展性好后期如果要做小程序或者App端直接复用后端的API就行了。网上超市系统就是一个很好的例子。前台用户浏览商品、加入购物车、下单支付这些操作全部通过Axios调用后端接口后台管理员管理商品、处理订单、查看统计图表同样是消费同一套API。前后端的边界在数据层划开各自为政又协同工作。提示真正动手之前花半天时间把前后端分离的基本概念搞清楚比多写几百行代码有价值得多。答辩时候这几乎是必考题做好准备不会吃亏。2. 核心业务模块拆解从订单状态机到库存扣减的设计思路很多同学写的毕业设计代码能跑但论文没东西可写答辩一段就冷场。原因很统一系统只有增删改查没有业务逻辑。网上超市系统不一样它天然包含了几个复杂的业务场景每个场景都能撑起论文里的一章。2.1 商品模块与购物车的表结构设计先看最基础的商品和购物车。很多初学者设计数据库的时候容易把表结构写得极其简单比如商品表就三个字段id、名字、价格。这样做的后果是后期一旦要扩展功能数据库就要大改。商品表我设计了两个独立的表商品信息表和商品分类表。商品信息表负责记录商品的名称、主图、轮播图URL、价格、库存、销量、上下架状态、创建时间等字段其中主图URL用于列表页的展示轮播图URL用于详情页的图片轮播。商品分类表则用来做一级和二级分类的树形存储比如食品饮料是一级分类碳酸饮料是二级分类。两者通过category_id字段关联。这样做的好处是前端要展示分类导航时后端只需一次联表查询就能返回完整的树形结构不需要在Java代码里做额外的递归组装。购物车表的设计也有讲究。购物车本身只是一个临时容器它不需要保存商品的完整信息只需要记录用户ID、商品ID、购买数量和勾选状态。真正下单生成订单时系统再去商品表读取最新的价格和库存而不是直接引用购物车里的快照数据。这一条看似是细节其实非常关键。否则的话如果管理员在用户加购后又调了价用户结算时看到的还是旧价格订单金额就和实际金额对不上了。2.2 订单状态机一个模型串起整个交易闭环订单模块是整个系统业务的枢纽。为什么这么说因为网上超市里几乎所有重要的业务动作最终都要落到订单状态的变化上。我设计的订单状态包括待支付、待发货、已发货、已完成、已取消。这几个状态两两之间有明确的方向约束比如只有待支付状态才能变为已取消只有已发货状态才能变为已完成。下单时扣减库存取消订单时返还库存这些操作都必须和状态流转绑定在同一个事务里。把状态机理清楚之后你会发现前端页面也变得好写了。用户中心的我的订单页面只需根据状态字段的值去渲染不同的操作按钮待支付显示去支付和取消订单待发货显示提醒发货已发货显示确认收货。所有逻辑都集中在一个状态字段上前端代码不会写得七零八落。2.3 库存扣减的并发陷阱一个真实的超卖案例说到库存我得讲一个我在测试阶段真正遇到过的bug。当时有两个人同时对一件库存只剩1件的商品发起下单请求结果系统生成了两个订单库存变成了-1。这就是典型的超卖问题。出现这个问题的原因很直接下单接口里的检查库存和扣减库存是两个独立的步骤中间隔了好几行代码。在高并发场景下线程A查到库存还有1件还没来得及扣减线程B也查到了库存还有1件两边同时通过校验都执行了扣减。解决方案其实并不复杂我的做法是在扣减库存的SQL语句上做文章不单独写查询拦截直接用带条件的UPDATE做原子操作UPDATE product SET stock stock - 1 WHERE id #{productId} AND stock 0;这行SQL的意思是只有当当前库存大于0的时候才执行扣减而且这个检查和更新的动作在数据库层面是原子的不会出现并发下的读取间隙。如果返回的受影响行数为0说明库存不足直接抛出异常、回滚整个下单事务即可。这个方案比用Java代码加synchronized锁要安全得多因为synchronized锁只对单个JVM实例内的线程有效而数据库的原子UPDATE是全局有效的不依赖部署环境。2.4 事务边界下单操作的完整流程下单这个动作涉及的操作不止一条插入订单主表记录、插入订单明细表记录、扣减商品库存、清空对应购物车项。任何一个环节失败前面做的操作都应该全部撤销否则就会出现订单生成了但库存没扣或者库存扣了但订单没生成这种数据不一致的问题。这里必须使用数据库事务。我建议把业务逻辑写在Service层的实现方法里并用Transactional注解标记整个方法为事务操作。需要注意的一点是事务的边界不能跨越外部调用。比如说如果下单后会调用模拟支付接口并同步扣减用户余额那么支付和下单必须在同一个事务内执行不能分在两个方法里各自开事务。我当时在A同学的版本里看到过一个典型的错误他先把订单插入和库存扣减做在一个事务里然后又单独写了一个加积分的方法也标注了事务。结果积分加成功了订单却因为网络原因回滚了积分就成了脏数据。这种问题很难被发现因为大多数时候接口是成功的只有极端情况下事务回滚才会暴露出来。3. 实测踩坑记录部署与联调中绕不开的六个问题这个项目在本地跑通和把它部署到一台全新服务器上跑通完全不是一回事。下面这六个问题是我把项目从能跑推向稳定运行的过程中实际遇到过、并逐一解决的每一个都有明确的排查链路你可以直接复制这套思路去排查你的环境。3.1 跨域请求被拦截问题永远在浏览器这一端前后端分离后前端页面运行在localhost:8080后端接口运行在localhost:9090只要前端页面加载后向后端发请求浏览器就会执行同源策略拦截掉这个跨域请求。界面上呈现出来的现象就是Axios报错Network面板里显示请求失败而后端日志里根本看不到这次请求到达。说白了这是浏览器的一种安全机制浏览器认为你不是同一个源那我不能让你随便互相访问。解决的方式非常统一在后端写一个全局的CORS配置类或者在SpringBoot的配置中通过addCorsMappings放行指定的路径和域名即可。我采用的是全局配置类的方式Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有几个细节值得注意。allowedOriginPatterns和allowCredentials不能同时使用*通配符——如果你允许携带Cookie就必须用具体的域名模式。另外放行的路径要尽量具体比如只放行/api/**不要放开所有路由这在安全性上会更好。3.2 金额字段到底该用Double还是BigDecimal这是我刻意要在早期说清楚的一个问题。网上超市系统的商品价格、订单金额、退款金额都属于精确计算场景如果数据库里的字段用double或者floatJava实体类里的属性也能写Double但在计算0.1 0.2这种小数运算时浮点数的二进制存储特性会让结果变成0.30000000000000004。订单里出现这种数字如果直接展示给用户看着就是低级事故。正确做法是数据库金额字段统一用decimal(10,2)Java实体类用BigDecimal类型。所有涉及加、减、乘、除的计算都通过BigDecimal的方法完成不要用原生运算符。我在实际测试中发现原始浮点运算的误差会在累计多笔订单时被放大到月底对账的时候对不上几毛钱都会让人头皮发麻。还有一个必须提醒的点BigDecimal的构造器尽量不要传Double类型比如new BigDecimal(0.1)生成的其实是一个二进制无限循环小数换算后的数字。正确的方式是new BigDecimal(0.1)用字符串构造。3.3 数据库连接时区导致的时间差8小时问题我第一次把项目部署到服务器之后发现后台管理页面的订单创建时间全部比实际时间晚了8个小时。查了半天最后定位到是MySQL连接配置里的时区参数问题。根因在MySQL驱动在连接数据库的时候需要一个serverTimezone参数。如果写的值是UTC存进去的时间就是按照UTC存储的而中国所在的时区是东八区GMT8取出来自然就慢了8小时。解决办法非常简单在jdbc连接URL里加上jdbc:mysql://localhost:3306/supermarket?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai配置改成Asia/Shanghai之后时间差问题立刻消失。这个坑很隐蔽因为它不会让程序报错只会在数据上静默地产生偏差稍不注意就会在答辩演示时闹笑话。3.4 自增主键用完了怎么办一张表引发的思考这个坑出现在测试数据造多了之后。我为了演示方便在开发环境往订单表里插了几十万条测试数据结果有一次插入新的订单记录时直接报错主键冲突了。原因在于订单表的主键采用的是int类型自增int类型的最大值是21亿左右当自增达到这个上限之后数据库无法再生成新的主键。对毕业设计来说int自增在演示量级下完全够用但如果你的论文里要写并发场景或者压测数据我建议直接把主键换成bigint这是防患于未然的最佳选择。另外还有一个习惯值得养成不要在程序里依赖自增主键作为业务编号对外展示尤其是订单号。订单号应该用专门生成的业务流水号比如根据时间戳加随机数生成18位的字符串这样即使同秒内有多个订单也不会重复。自增主键只做内部关联使用。3.5 事务回滚失效这个错误七成人都会犯有一个高频的代码错误在踩坑记录里必须占一个位置——事务没有生效。事务生效的前提是方法被Spring的代理对象调用。什么意思呢就是你调用this.orderService.placeOrder()这种方法如果这个方法是在同一个类内部通过this调用的那Spring事务管理器根本感知不到这次调用Transactional注解就等于白写了。我在A同学的代码里看到过这种写法public void processOrder(Long orderId) { payOrder(orderId); deductStock(orderId); } Transactional public void payOrder(Long orderId) { ... }processOrder方法在同一个类里直接调用payOrder此时payOrder上的Transactional注解不会生效。因为Spring的AOP代理是基于外部调用拦截的this调用不走代理。正确的姿势是把事务方法放在一个独立服务里或者让processOrder方法自身也标注Transactional。注意这是毕业设计答辩中很容易被老师追问的点。如果老师问你事务为什么没生效你要能从代理机制的角度解释清楚直接说出调this方法不走代理这个关键点分数会高很多。3.6 前端打完包后端接口404了本地开发一切正常部署到服务器之后页面能打开但接口请求全部404。这个现象本质上是前后端分离部署方案不统一导致的。我的做法是前端在本地执行npm run build生成dist目录后端SpringBoot的src/main/resources/static目录用来存放静态资源。我把dist目录下的文件复制到static目录里这样SpringBoot启动后就会同时托管前端页面和后端API。从外部看所有请求都访问同一个端口既解决了跨域问题也让部署变得极其简单——一个jar包搞定全部内容。如果你的项目采用前后端完全分开部署的方式比如前端用Nginx后端用独立端口那就必须保证Nginx配置了/api路径的反向代理。两种方案各有优劣对毕业设计而言SpringBoot托管静态文件的方式最省事演示的时候也不用担心Network面板里出现红字请求。4. 后端业务层的关键实现分页、登录、权限校验把坑说完来说具体的代码实现。我这里不打算贴大段的完整代码挑几个核心点讲做项目必须理解透彻的部分。4.1 商品分页查询与条件筛选网上超市的商品列表页必须支持分页和筛选这也是后端非常高频的一个接口。SpringBoot搭配MyBatis Plus体验极佳自带分页插件不需要手动写LIMIT。我在商品Controller里写的接口签名大致是接收页码、每页条数、商品名称关键字、分类ID、上下架状态这几个参数返回一个统一封装的JSON对象包含总记录数、总页数、当前页数据和当前页码。调用MyBatis Plus的Page对象后直接selectPage就能拿到分页结果非常干净PageProduct page new Page(pageNum, pageSize); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(categoryId), Product::getCategoryId, categoryId) .like(StringUtils.isNotBlank(keyword), Product::getName, keyword) .eq(status ! null, Product::getStatus, status) .orderByDesc(Product::getCreateTime); productMapper.selectPage(page, wrapper);这段代码的精髓在于LambdaQueryWrapper的条件构造——通过eq、like这类方法把动态SQL的条件全部拼接好一旦对应的参数为空就跳过这个条件从而完美支持用户不筛选时查出全部商品的需求。4.2 登录态与JWT无状态鉴权前端登录之后后端如何知道后续的每次请求都来自同一个用户这里我采用的是JWTJSON Web Token方案。用户提交账号密码后后端校验User表里的记录验证通过则利用用户的ID、用户名、角色等信息生成一个带签名和过期时间的Token返回给前端。前端把它存在localStorage里每次请求时在Header里带上Authorization字段。后端拦截器读取Token解密校验确认用户身份没问题才放行请求。这个方案最大的优点是后端不需要存储Session就能实现用户身份验证天然适配前后端分离的场景。需要注意生成Token时的密钥要保存在后端配置文件里不要硬编码在前端代码中过期时间一般设置2小时超时需要重新登录。4.3 角色权限的拦截设计网上超市系统里至少有两类角色普通用户和管理员。管理员拥有管理商品、处理订单、管理分类等后端接口的权限普通用户只能访问前台接口和自己的订单数据。我采用的权限方案是做一个拦截器Interceptor在preHandle方法中读取当前用户的角色字段再判断当前请求的路径是否落在管理员专属路由下。如果角色不符直接返回403。实际开发中如果你愿意往深一点做可以用Spring Security的注解权限控制比如PreAuthorize(hasRole(ADMIN))这样每个Controller的方法上都能声明自己需要什么角色代码表达了更多语义老师们也会更欣赏这种设计。5. 前端页面的搭建思路路由权限与状态管理Vue前端部分我通常建议同学们优先把三种能力练熟路由守卫、Axios封装、组件状态传递。这三样练会了整个项目就算骨架扎实了。5.1 路由设计用户端和管理端是两个独立空间网上超市的前端路由应该分成两套来访宾客与管理后台动态登录页面互不干扰。用户端包括首页、商品列表页、商品详情页、购物车页、结算页、个人中心等。管理端包括管理员登录页、商品管理页、订单管理页、分类管理页、数据统计图表页。我建议把这两套页面用路由前缀区分比如管理端统一挂在/admin下然后在路由配置里设置一个守卫函数如果访问的是/admin开头的路径就检查本地是否存有登录后的Token如果没有就强制跳转到管理员登录页。这个前端守卫的效果是页面级的不可靠也没关系因为后端接口还有一层拦截器在兜底。你永远不能只靠前端挡人后端才是安全检查的最后一道闸门。5.2 Axios封装统一处理错误与Token几乎所有请求都要做的三件事不值得在每一个组件里反复写。我建议封装一个统一的request工具用Axios实例的拦截器来处理请求拦截器从localStorage读取Token塞到Authorization头里。响应拦截器如果返回的HTTP状态码是401说明Token过期或未登录这时清空本地登录信息并跳转到登录页如果是403弹出没有权限提示。网络或业务错误码则统一弹出错误信息避免前端组件里分散写各种message调用。网上超市这类系统的前端代码量不小但绝大部分都在做跟业务相关的展示逻辑。把公共的能力收到工具里你的页面代码会好维护得多。5.3 购物车页面的响应式数据设计购物车组件是整个前端里状态最复杂的一个。它的数据量不大但多个子组件之间需要实时同步。我的做法是在进入购物车页面时通过接口把当前用户的购物车列表一次性拿回来存放在Vuex或Pinia的store里。全选、单选、修改数量、删除商品所有操作都走store的actions函数把新的勾选状态同步到后端接口再更新本地状态。这样页面上的已选商品数量和合计金额两个展示区只需要依赖store里的getter实时计算不需要手动去改DOM里的文本。用Vue框架最值钱的一个思维是数据驱动视图。你要把精力放在如何管理好数据而不是如何操控DOM。6. 论文撰写与答辩怎么把项目讲成一个完整的故事代码写完了部署好了下一步就是论文和答辩。很多同学栽在这一步——代码明明能跑论文却写得像流水账答辩时根本不知道讲什么。我给大家拆一下论文的结构逻辑。6.1 毕业论文的章节脉络推荐按我这边的惯例这种系统开发类的毕业设计论文正文合理规划后一般是这样分布的绪论部分交代课题研究背景、意义和国内外现状系统需求分析里要分清楚功能性需求和非功能性需求比如登录、商品浏览、下单这些是功能性需求系统的响应时间、并发能力、安全要求是非功能性需求系统设计部分从总体架构图开始往下细化到功能模块划分、数据库表设计、接口设计系统实现部分按模块逐个讲实现细节和关键代码系统测试部分列出测试用例表和执行结果这部分工作量看起来很实也容易写。论文的核心逻辑是需求分析决定你要做什么系统设计决定你怎么做系统实现展示你做出来的东西系统测试证明你做的东西没问题。这四个章节前后要能对得上不能需求里提了十个功能实现部分只写了八个。6.2 图表与代码的平衡老师拿到一篇论文翻看得最多的就是图。所以我建议四类图务必做好系统总体架构图、功能模块图、数据库E-R图、核心业务时序图。这几张图做精致了论文框架就已经打好了一半。代码在论文正文里只放核心片段能够说明实现思路就够了大段代码可以放附录。放代码的时候记得加中文注释这对老师快速理解你的代码意图非常有帮助。6.3 答辩时的演示准备清单答辩演示常见的问题是操作太流畅老师反而看不出项目的能力。我建议演示前先做两件事准备好演示数据不要空库演示商品、订单、用户数据尽量真实设计好演示脚本前台从注册登录到下单支付走一遍后台从商品上下架到订单发货走一遍时间控制在8-10分钟。答辩老师最喜欢追问的往往是你这个模块如果遇到XX情况会怎么样比如库存超卖、用户重复点击下单、权限绕过。所以演示之余把我在第3节里讲的那几个问题都提前想一遍不用背答案理解原理之后自然能应对。最后再提醒一句毕业设计最重要的是完整的交付物和清晰的思考过程不是你写了多少行代码。技术栈可以不新但业务逻辑必须闭环文档必须齐全。把网上超市系统从需求分析到测试部署完整走一遍这个过程本身就是最好的答辩准备。