做了几个学期的辅助指导之后，我越发觉得一件事是真的：很多同学毕业设计做得辛苦，其实不是不会写代码，而是根本不知道一个项目该从哪里下手。拿这次要说的"网上超市"系统来说，SpringBoot + Vue + MySQL这套组合，几乎每个计算机专业学生都听过，但把它真正落地成一个能演示、能答辩、能写进论文的完整项目，涉及到的细节远比想象中多。
这篇文章我想换个讲法，不给你们贴那种"书本式"的教程，而是把这个项目从选型到部署、从代码到论文的全过程拆开聊。所有内容包括项目正文、源码、数据库脚本、论文框架和部署文档，都是围绕一个完整的网上超市系统展开。无论你是打算照着做一遍，还是想理解每个模块为什么这么设计，这篇文章应该都能给你提供一个清晰的地图。
1. 为什么说SpringBoot + Vue + MySQL是毕业设计的"安全牌"
每年到毕业季，我都会收到一批私信，问的大同小异：老师要求做一个管理系统，到底用什么技术栈比较稳？我的回答通常只有一个：SpringBoot + Vue + MySQL。这套组合看起来没什么花样，但恰恰因为没花样，它的确定性最高。
1.1 从技术选型的底层逻辑聊起
先说后端。SpringBoot之所以成为主流，核心在于它把配置简化到了极致。过去用SSM（Spring + 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或者float，Java实体类里的属性也能写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存储的，而中国所在的时区是东八区（GMT+8），取出来自然就慢了8小时。解决办法非常简单，在jdbc连接URL里加上：
jdbc:mysql://localhost:3306/supermarket?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/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就能拿到分页结果，非常干净：
Page<Product> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Product> 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无状态鉴权
前端登录之后，后端如何知道后续的每次请求都来自同一个用户？这里我采用的是JWT（JSON 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节里讲的那几个问题都提前想一遍，不用背答案，理解原理之后自然能应对。
最后再提醒一句：毕业设计最重要的是完整的交付物和清晰的思考过程，不是你写了多少行代码。技术栈可以不新，但业务逻辑必须闭环，文档必须齐全。把网上超市系统从需求分析到测试部署完整走一遍，这个过程本身就是最好的答辩准备。
