直接说结论这套“衣依”服装销售平台是我见过最适合拿来毕业设计答辩的前后端分离项目之一。SpringBoot Vue的技术栈非常常规但它的价值恰恰在于“常规”——评审老师不会因为框架太偏而刁难你数据库设计、接口文档、前后端数据交互这些关键得分点又都覆盖到了。这篇文章不吹不黑我以“拿到手之后怎么吃透、怎么跑通、怎么改成自己的、怎么讲给老师听”为主线把整个项目从头到尾拆一遍。无论你是想直接复现还是想基于它做二次开发都能找到参照。1. 先看门面拆解“衣依”的工程结构与交付物1.1 压缩包里到底有什么拿到这套源码第一件事不是点运行而是先盘一盘“家底”。解压之后通常会看到这些内容这也是大多数高质量毕设项目的标准交付格式yi-clothing/ ├── backend/ # SpringBoot后端工程 │ ├── src/main/java │ ├── src/main/resources │ └── pom.xml ├── frontend/ # Vue前端工程 │ ├── src/ │ ├── package.json │ └── vue.config.js ├── sql/ │ └── yi_clothing.sql └── 接口文档.md或doc文件夹前后端分离的目录结构本身就是第一个答辩得分点。老师一眼就能看出你对工程化有概念——不是那种把页面和后台代码混在一起的单体JSP项目。sql/目录单独放脚本也说明你有“数据是独立资产”的意识。1.2 前端Vue和后端SpringBoot的目录结构后端的主包名通常是com.yiyi.controller、com.yiyi.service、com.yiyi.mapper这种三层结构。你可以把controller当成“前台接待”service是“业务大脑”mapper跟数据库打交道。顺序永远是Controller调ServiceService调Mapper禁止跨层调用这个约定俗成的规范在答辩时被问到的概率极高。前端方面“衣依”用的是标准Vue脚手架src/views下一般按业务模块分文件夹——home、goods、cart、order、user。这里有个细节值得学习路由配置文件router/index.js用到了懒加载component: () import(...)而不是顶部一股脑全部引入。这样做的好处是首屏加载更快面试问到性能优化时你也有话可说。1.3 这份源码解决了毕设评审最关心的三个问题完整性从用户注册登录到下单支付流程支付一般是模拟到后台管理一条龙闭环没有“缺胳膊少腿”的模块。规范性接口文档齐全数据库脚本可直接导入说明项目不只是能跑还可以被他人复现。有深度不是只有增删改查订单状态流转、购物车数量修改这种“有点业务逻辑”的功能正好卡在毕设要求的难度档位。2. 从SQL脚本反推业务蓝图数据库里的“衣依”打开yi_clothing.sql我建议你先别急着导入数据库花半小时通读一遍建表语句。读懂了表结构整个系统的业务逻辑就懂了一大半。2.1 核心表结构的精读笔记典型的服装销售平台核心表至少包括这些user用户表主键id、username、password、phone、avatar等。注意password在真实项目里会加密但毕设里很多直接存明文。你要做二次开发强烈建议至少改成MD5加盐或者BCrypt这个点可以在答辩时主动提出来讲显得你有安全意识。goods商品表name、price、stock、cover封面图、images详情轮播图、detail商品详情富文本。服装类的detail字段通常很长所以设计上一般用TEXT类型而不是VARCHAR。cart购物车表user_id、goods_id、count。这里的主键建议是联合主键userId goodsId防止同一用户把同一件商品加入购物车多次出现重复行。orders订单表orderNo订单编号、totalPrice、userId、addressId、status。订单表是核心中的核心它承载了整个交易链路的状态记录。order_item订单明细表order_id、goods_id、goods_name、price、count。为什么要拆一张明细表因为下单之后商品可能改价、可能下架你必须在订单里“快照”下单那一刻的商品信息这是典型的“一主多从”设计思路。2.2 不显眼但很关键的几张“配角表”carousel轮播图表管理首页滚动横幅。很多新手会把这个数据写死在页面里但“衣依”把它做成表意味着后台可以动态控制展示内容这是区分“demo”和“系统”的细节之一。address收货地址表user_id、consignee、phone、province、city、district、detail。如果要加“设为默认地址”功能只需要加一个is_default字段。admin管理员表榜单里存管理员账号和前端用户表分开权限边界从一开始就划清了。如果想做更细粒度的权限控制比如商品管理员、订单管理员在这个表基础上扩展role字段即可。2.3 SQL脚本导入的实操注意点有人导入SQL时报错Unknown collation: utf8mb4_0900_ai_ci八成是MySQL版本不对。utf8mb4_0900_ai_ci是MySQL 8.0的默认排序规则如果你的环境是5.7可以用文本编辑器全局替换成utf8mb4_general_ci就能顺利导入了。如果脚本里没有建库语句CREATE DATABASE你需要在Navicat或命令行里手动创建yi_clothing库然后选择该库再导入。导入成功后重点检查三张表goods商品表有没有测试数据、carousel轮播图有没有配图、orders订单表是不是空表。没有测试数据的话首页展示会很空跑通后看起来“营养不良”。3. 前端页面的“销售动线”Vue如何组织电商体验3.1 路由设计背后的用户行为链路“衣依”前端的路由设计本质上是电商用户动线的直观映射游客逛首页 → 点商品进详情 → 注册登录 → 加入购物车 → 去结算填写地址 → 提交订单 → 支付 → 查看订单状态。你打开router/index.js会看到路由清晰地分为两部分用户端页面和管理后台。用户端有首页、商品详情、购物车、订单列表、个人信息几个核心页面。后台则包含商品管理、订单管理、用户管理、轮播图管理。前端路由的守卫beforeEach通常会做登录校验——没登录就跳转到登录页。这里有几个实现细节值得关注首页数据请求通常放在created或mounted钩子中。用created更合适因为此时组件实例已经创建但DOM尚未渲染数据拉回来正好配合渲染感知上更快。商品详情页从URL取idthis.$route.params.id然后拉取详情接口。如果你在详情页刷新后404多半是路由配置漏了/:id的动态路径。购物车页的“全选/反选/合计金额”功能核心是一个computed计算属性去遍历购物车列表、累加选中的商品价格。这套逻辑完全可以迁移到任何电商类项目。3.2 组件化程度哪里写得好哪里可以二次改造“衣依”的组件化做得中规中矩公共部分基本抽成了组件比如商品卡片GoodsCard、分页条Pagination、头部导航Navbar。这符合毕设要求但也留下了大量可以自我发挥的空间。二次开发时的几个低成本高回报改造方向把商品卡片组件进一步抽象增加props传入模式网格/列表切换让首页和搜索结果页共用同一种卡片不同布局。全局引入vue-lazyload做图片懒加载商品列表图片一多加载体验会直观改善。用vuex集中管理用户登录态和购物车数量。原项目可能每处都用localStorage直接读改成Pinia或Vuex管理算是一次架构级别的小升级答辩论据也充分。增加loading过渡动画。毕设现场演示最怕点开页面一片空白哪怕数据只有几十毫秒延迟加个v-loading效果都会显得挺像回事。3.3 前后端联调的关键细节“衣依”后端接口的端口通常是8080Vue开发服务器跑在8081所以必须配代理转发才能请求到接口。vue.config.js里的配置大致长这样module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这个配置的意思是前端所有以/api开头的请求都会被代理转发到后端的8080端口上。这样前端写axios请求时baseURL直接写/api绕开了跨域问题。但有个经常踩的坑如果后端接口实际路径没有/api前缀比如后端Controller是RequestMapping(/goods)你会在浏览器里看到404。解决办法是在后端统一加一个server.servlet.context-path/api配置或者在Controller的RequestMapping里统一带上前缀。前后端分离项目里这种“前缀不匹配”引起的踩坑率非常高排查时可以先看浏览器Network面板里的真实请求URL。4. 后端接口的“话外之音”Controller、订单状态与并发隐患4.1 接口文档里没显式写明的三层逻辑接口文档通常按模块列出URL、请求方式、参数、返回值样例。“衣依”的接口文档覆盖了登录注册、商品浏览、购物车操作、订单提交、后台管理等模块。但看文档不只是“对着调通接口”你还要在脑子里形成一张后端处理地图登录接口前端把用户名、密码POST给后端后端校验成功后一般返回token有时就是一个UUID或用户对象。如果返回的是用户对象前端就没有做会话保持刷新页面就可能掉登录态需要自行封装拦截器去补齐。首页数据聚合接口一个个请求太慢优秀设计是做一个聚合接口一次返回轮播图、热门商品、新品推荐。毕设阶段不要求你写这种高并发接口但如果愿意额外实现答辩时能讲出“性能优化”的故事。下单接口它的业务逻辑是最复杂的——校验库存、计算金额、扣库存、生成订单号和订单明细、清空购物车。有一个题点几乎必被老师问到“要保证订单扣库存的一致性你是怎么处理的”这时候就算你用的是最基础的UPDATE goods SET stock stock - #{count} WHERE id #{id} AND stock #{count}行锁乐观方案也算是对“并发控制”有意识。4.2 订单状态流转的背后逻辑“衣依”的订单状态一般用数字或字符串标识常见状态是状态值含义对应前端显示0待付款待付款1待发货待发货2待收货待收货3已完成已完成4已取消已取消这个流转顺序是有严格业务含义的用户下单后是待付款付款之后商家发货发货后变成待收货用户确认收货后完成。后端的updateStatus接口通常只做“由当前状态流转到下一状态”的校验不允许乱跳。这块如果要用代码保护起来可以在Service里依次判断当前状态是否符合期望的流转路径不符合就抛出异常。老师看到这里会觉得你是真做过业务系统的不是写着玩的。4.3 库存扣减的“多卖超卖”陷阱如果用户并发点击“立即购买”提交订单后端每次查询库存时看到库存都大于0就可能卖出超出库存数量的商品。毕设阶段不要求引入Redis分布式锁或消息队列但你要能主动说出来“这里可以做防超卖处理”。最简单可落地的写法如下-- 扣减库存时带上库存充足条件 UPDATE goods SET stock stock - 1 WHERE id #{goodsId} AND stock 0然后在Service外层判断受影响行数int rows goodsMapper.deductStock(goodsId);如果rows 0就说明库存不足回滚事务并提示用户。这个方案像“数据库层的乐观锁”是后面面试时一个很讨巧的亮点。原项目如果没做这一步你在二次开发时把它补上直接在答辩时跟老师讲明白“我做了并发下的超卖防范”叙事立刻不一样。“衣依”的application.yml里需要spring.datasource.driver-class-name、url、username、password实际主要就这一块别弄错。MySQL版本高的话记得把时区参数加上spring: datasource: url: jdbc:mysql://localhost:3306/yi_clothing?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai如果遇到Access denied for user rootlocalhost检查用户名密码是否写对root不只一个可能密码中包含特殊字符导致YAML解析出错。还有一点容易踩项目启动后端口被占用报Port 8080 already in use。解决办法要么杀掉占用进程macOS/Linux上lsof -i:8080Windows上netstat -ano | findstr :8080要么在application.yml里换成8082端口。前端代理也需要同步改。5.2 启动顺序是门玄学正确的操作顺序是先启动MySQL服务 → 导入SQL脚本 → 启动后端SpringBoot → 启动前端Vue → 浏览器访问。顺序反了不是起不来就是启动后接口报错。后端启动成功的标志是控制台出现Tomcat started on port(s): 8080而不是BUILD SUCCESS。很多人看到BUILD SUCCESS就以为成功了其实是编译通过但还没启起来。然后前端在终端执行npm run serve出现App running at: http://localhost:8081就是成功。这两个标志记住判断“系统是否正常”就心里有底了。如果后端启动直接失败关键报错大多出现在Caused by那一行。看清具体是哪类错误再改找不到驱动类八成是Maven没拉全依赖连接被拒八成是MySQL没启动表不存在是脚本没导入或者库名对不上。解决顺序也有讲究先解决数据库再解决端口最后才看代码逻辑。5.3 功能自测清单别等到演示现场才手忙脚乱项目跑通后按照这套“用户动线”完整走一遍确认每个环节都正常用户注册一个新账号确认手机号和用户名校验生效。用新账号登录确认页面顶部状态从“未登录”变为用户昵称。首页点击任意商品进入详情页确认商品图、价格、库存显示正常。修改商品数量加入购物车确认购物车列表数量和总价正确。点击结算填写/选择收货地址提交订单确认生成订单号。模拟支付确认订单状态变为待发货。用管理员账号登录后台确认能查看这笔订单并可以发货。用户端刷新订单状态确认变为待收货。这套流程你最好走两遍一遍是登录状态正常的情况一遍是登录状态过期、强制刷新页面后的情况。很多毕设演示翻车就栽在“演示时一切正常但老师要求刷新页面后前端没带token接口401报错页面白屏”。提前把这些边界情况都测一遍是你答辩状态从容的关键。6. 把“成品”变成“自己的”二次开发与答辩讲法6.1 低成本改动就能有明显辨识度直接用原项目答辩最怕老师问“这个项目跟你有什么关系”。所以二次开发是几乎必须的。低成本又有辨识度的方向包括商品搜索功能后端加一个SELECT * FROM goods WHERE name LIKE %keyword%前端在导航栏加一个搜索框跳转到搜索结果页。整个改动工作量半天以内但项目立刻有了“搜索”模块。商品分类筛选给goods表加一个category字段首页将“全部商品”按T恤、衬衫、外套、裤装分区展示。后端加一个category参数即可前端做一个Tab切换。收货地址的增删改查原项目如果只有下单时选地址你可以把这个做成独立的“地址管理”页面这属于“补全用户账户体系”的顺理成章优化。图片上传后台新增商品时如果能支持本地上传图片上传到项目目录前端通过一个映射路径显示这个功能的工程意义比手动往SQL里塞Base64图片要大得多。6.2 答辩时怎么讲这套系统答辩陈述的核心逻辑是讲场景 → 讲技术 → 讲难点 → 讲验证顺着这条线讲老师会被你带着走。讲场景“我设计的是一个服装销售平台面向用户提供在线浏览、加购、下单等能力面向管理员提供商品上下架和订单处理能力。”讲技术拆分“前端用Vue Element UI搭建页面通过Axios与后端SpringBoot通信后端采用分层架构Controller负责路由分发Service承载业务逻辑Mapper对接MySQL数据库。”讲难点“整个系统最复杂的业务逻辑就是下单需要校验购物车、计算金额、扣减库存、生成订单明细、清空购物车还要保证并发下库存不超卖我通过数据库层的条件更新解决了这个问题。”讲验证“我完整走通了注册、登录、加购、下单、支付、发货、收货的完整流程并且测试了重复下单、库存不足等情况。”这四个点串起来一个清晰的系统叙事就成型了。老师听下来觉得你既懂原理又重验证基本不会再追问过深。6.3 二次开发时最容易翻车的三个点第一个坑是改代码时把前后端接口路径改岔了。前端axios请求路径和后端RequestMapping必须严格对齐少一个/或大小写不一致都是404排查时优先看Network面板标红的请求。第二个坑是数据库字段改了但实体类和Mapper没同步。给goods加了一个字段却忘了改Goods.java实体类运行起来就是Invalid column报错。对应关系要同步改这是Java Web最基本也最常犯的错误。第三个坑是改了前端组件后忘了重新构建。后端改完需要重启SpringBoot前端改完如果访问的是dist目录打包产物还得重新执行npm run build。用开发方式npm run serve时确实热更新不用管但如果部署到生产环境忘记构建这件事是爆炸级别翻车。你说它有多深不至于。但作为一套完整交付的毕设它在“跑通”“讲清”“可改”三维度上做得相当扎实。如果你现在手头正缺一个Java Web毕设项目这套源码是一个很值得花时间的底座。方向有了剩下的就是动手。一步步把数据库脚本导进去、把前后端跑起来、把每个接口读明白再用自己的思路改掉一部分代码这就是最稳的毕业设计打开方式。
SpringBoot+Vue前后端分离服装销售平台毕业设计项目全解析
直接说结论这套“衣依”服装销售平台是我见过最适合拿来毕业设计答辩的前后端分离项目之一。SpringBoot Vue的技术栈非常常规但它的价值恰恰在于“常规”——评审老师不会因为框架太偏而刁难你数据库设计、接口文档、前后端数据交互这些关键得分点又都覆盖到了。这篇文章不吹不黑我以“拿到手之后怎么吃透、怎么跑通、怎么改成自己的、怎么讲给老师听”为主线把整个项目从头到尾拆一遍。无论你是想直接复现还是想基于它做二次开发都能找到参照。1. 先看门面拆解“衣依”的工程结构与交付物1.1 压缩包里到底有什么拿到这套源码第一件事不是点运行而是先盘一盘“家底”。解压之后通常会看到这些内容这也是大多数高质量毕设项目的标准交付格式yi-clothing/ ├── backend/ # SpringBoot后端工程 │ ├── src/main/java │ ├── src/main/resources │ └── pom.xml ├── frontend/ # Vue前端工程 │ ├── src/ │ ├── package.json │ └── vue.config.js ├── sql/ │ └── yi_clothing.sql └── 接口文档.md或doc文件夹前后端分离的目录结构本身就是第一个答辩得分点。老师一眼就能看出你对工程化有概念——不是那种把页面和后台代码混在一起的单体JSP项目。sql/目录单独放脚本也说明你有“数据是独立资产”的意识。1.2 前端Vue和后端SpringBoot的目录结构后端的主包名通常是com.yiyi.controller、com.yiyi.service、com.yiyi.mapper这种三层结构。你可以把controller当成“前台接待”service是“业务大脑”mapper跟数据库打交道。顺序永远是Controller调ServiceService调Mapper禁止跨层调用这个约定俗成的规范在答辩时被问到的概率极高。前端方面“衣依”用的是标准Vue脚手架src/views下一般按业务模块分文件夹——home、goods、cart、order、user。这里有个细节值得学习路由配置文件router/index.js用到了懒加载component: () import(...)而不是顶部一股脑全部引入。这样做的好处是首屏加载更快面试问到性能优化时你也有话可说。1.3 这份源码解决了毕设评审最关心的三个问题完整性从用户注册登录到下单支付流程支付一般是模拟到后台管理一条龙闭环没有“缺胳膊少腿”的模块。规范性接口文档齐全数据库脚本可直接导入说明项目不只是能跑还可以被他人复现。有深度不是只有增删改查订单状态流转、购物车数量修改这种“有点业务逻辑”的功能正好卡在毕设要求的难度档位。2. 从SQL脚本反推业务蓝图数据库里的“衣依”打开yi_clothing.sql我建议你先别急着导入数据库花半小时通读一遍建表语句。读懂了表结构整个系统的业务逻辑就懂了一大半。2.1 核心表结构的精读笔记典型的服装销售平台核心表至少包括这些user用户表主键id、username、password、phone、avatar等。注意password在真实项目里会加密但毕设里很多直接存明文。你要做二次开发强烈建议至少改成MD5加盐或者BCrypt这个点可以在答辩时主动提出来讲显得你有安全意识。goods商品表name、price、stock、cover封面图、images详情轮播图、detail商品详情富文本。服装类的detail字段通常很长所以设计上一般用TEXT类型而不是VARCHAR。cart购物车表user_id、goods_id、count。这里的主键建议是联合主键userId goodsId防止同一用户把同一件商品加入购物车多次出现重复行。orders订单表orderNo订单编号、totalPrice、userId、addressId、status。订单表是核心中的核心它承载了整个交易链路的状态记录。order_item订单明细表order_id、goods_id、goods_name、price、count。为什么要拆一张明细表因为下单之后商品可能改价、可能下架你必须在订单里“快照”下单那一刻的商品信息这是典型的“一主多从”设计思路。2.2 不显眼但很关键的几张“配角表”carousel轮播图表管理首页滚动横幅。很多新手会把这个数据写死在页面里但“衣依”把它做成表意味着后台可以动态控制展示内容这是区分“demo”和“系统”的细节之一。address收货地址表user_id、consignee、phone、province、city、district、detail。如果要加“设为默认地址”功能只需要加一个is_default字段。admin管理员表榜单里存管理员账号和前端用户表分开权限边界从一开始就划清了。如果想做更细粒度的权限控制比如商品管理员、订单管理员在这个表基础上扩展role字段即可。2.3 SQL脚本导入的实操注意点有人导入SQL时报错Unknown collation: utf8mb4_0900_ai_ci八成是MySQL版本不对。utf8mb4_0900_ai_ci是MySQL 8.0的默认排序规则如果你的环境是5.7可以用文本编辑器全局替换成utf8mb4_general_ci就能顺利导入了。如果脚本里没有建库语句CREATE DATABASE你需要在Navicat或命令行里手动创建yi_clothing库然后选择该库再导入。导入成功后重点检查三张表goods商品表有没有测试数据、carousel轮播图有没有配图、orders订单表是不是空表。没有测试数据的话首页展示会很空跑通后看起来“营养不良”。3. 前端页面的“销售动线”Vue如何组织电商体验3.1 路由设计背后的用户行为链路“衣依”前端的路由设计本质上是电商用户动线的直观映射游客逛首页 → 点商品进详情 → 注册登录 → 加入购物车 → 去结算填写地址 → 提交订单 → 支付 → 查看订单状态。你打开router/index.js会看到路由清晰地分为两部分用户端页面和管理后台。用户端有首页、商品详情、购物车、订单列表、个人信息几个核心页面。后台则包含商品管理、订单管理、用户管理、轮播图管理。前端路由的守卫beforeEach通常会做登录校验——没登录就跳转到登录页。这里有几个实现细节值得关注首页数据请求通常放在created或mounted钩子中。用created更合适因为此时组件实例已经创建但DOM尚未渲染数据拉回来正好配合渲染感知上更快。商品详情页从URL取idthis.$route.params.id然后拉取详情接口。如果你在详情页刷新后404多半是路由配置漏了/:id的动态路径。购物车页的“全选/反选/合计金额”功能核心是一个computed计算属性去遍历购物车列表、累加选中的商品价格。这套逻辑完全可以迁移到任何电商类项目。3.2 组件化程度哪里写得好哪里可以二次改造“衣依”的组件化做得中规中矩公共部分基本抽成了组件比如商品卡片GoodsCard、分页条Pagination、头部导航Navbar。这符合毕设要求但也留下了大量可以自我发挥的空间。二次开发时的几个低成本高回报改造方向把商品卡片组件进一步抽象增加props传入模式网格/列表切换让首页和搜索结果页共用同一种卡片不同布局。全局引入vue-lazyload做图片懒加载商品列表图片一多加载体验会直观改善。用vuex集中管理用户登录态和购物车数量。原项目可能每处都用localStorage直接读改成Pinia或Vuex管理算是一次架构级别的小升级答辩论据也充分。增加loading过渡动画。毕设现场演示最怕点开页面一片空白哪怕数据只有几十毫秒延迟加个v-loading效果都会显得挺像回事。3.3 前后端联调的关键细节“衣依”后端接口的端口通常是8080Vue开发服务器跑在8081所以必须配代理转发才能请求到接口。vue.config.js里的配置大致长这样module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这个配置的意思是前端所有以/api开头的请求都会被代理转发到后端的8080端口上。这样前端写axios请求时baseURL直接写/api绕开了跨域问题。但有个经常踩的坑如果后端接口实际路径没有/api前缀比如后端Controller是RequestMapping(/goods)你会在浏览器里看到404。解决办法是在后端统一加一个server.servlet.context-path/api配置或者在Controller的RequestMapping里统一带上前缀。前后端分离项目里这种“前缀不匹配”引起的踩坑率非常高排查时可以先看浏览器Network面板里的真实请求URL。4. 后端接口的“话外之音”Controller、订单状态与并发隐患4.1 接口文档里没显式写明的三层逻辑接口文档通常按模块列出URL、请求方式、参数、返回值样例。“衣依”的接口文档覆盖了登录注册、商品浏览、购物车操作、订单提交、后台管理等模块。但看文档不只是“对着调通接口”你还要在脑子里形成一张后端处理地图登录接口前端把用户名、密码POST给后端后端校验成功后一般返回token有时就是一个UUID或用户对象。如果返回的是用户对象前端就没有做会话保持刷新页面就可能掉登录态需要自行封装拦截器去补齐。首页数据聚合接口一个个请求太慢优秀设计是做一个聚合接口一次返回轮播图、热门商品、新品推荐。毕设阶段不要求你写这种高并发接口但如果愿意额外实现答辩时能讲出“性能优化”的故事。下单接口它的业务逻辑是最复杂的——校验库存、计算金额、扣库存、生成订单号和订单明细、清空购物车。有一个题点几乎必被老师问到“要保证订单扣库存的一致性你是怎么处理的”这时候就算你用的是最基础的UPDATE goods SET stock stock - #{count} WHERE id #{id} AND stock #{count}行锁乐观方案也算是对“并发控制”有意识。4.2 订单状态流转的背后逻辑“衣依”的订单状态一般用数字或字符串标识常见状态是状态值含义对应前端显示0待付款待付款1待发货待发货2待收货待收货3已完成已完成4已取消已取消这个流转顺序是有严格业务含义的用户下单后是待付款付款之后商家发货发货后变成待收货用户确认收货后完成。后端的updateStatus接口通常只做“由当前状态流转到下一状态”的校验不允许乱跳。这块如果要用代码保护起来可以在Service里依次判断当前状态是否符合期望的流转路径不符合就抛出异常。老师看到这里会觉得你是真做过业务系统的不是写着玩的。4.3 库存扣减的“多卖超卖”陷阱如果用户并发点击“立即购买”提交订单后端每次查询库存时看到库存都大于0就可能卖出超出库存数量的商品。毕设阶段不要求引入Redis分布式锁或消息队列但你要能主动说出来“这里可以做防超卖处理”。最简单可落地的写法如下-- 扣减库存时带上库存充足条件 UPDATE goods SET stock stock - 1 WHERE id #{goodsId} AND stock 0然后在Service外层判断受影响行数int rows goodsMapper.deductStock(goodsId);如果rows 0就说明库存不足回滚事务并提示用户。这个方案像“数据库层的乐观锁”是后面面试时一个很讨巧的亮点。原项目如果没做这一步你在二次开发时把它补上直接在答辩时跟老师讲明白“我做了并发下的超卖防范”叙事立刻不一样。“衣依”的application.yml里需要spring.datasource.driver-class-name、url、username、password实际主要就这一块别弄错。MySQL版本高的话记得把时区参数加上spring: datasource: url: jdbc:mysql://localhost:3306/yi_clothing?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai如果遇到Access denied for user rootlocalhost检查用户名密码是否写对root不只一个可能密码中包含特殊字符导致YAML解析出错。还有一点容易踩项目启动后端口被占用报Port 8080 already in use。解决办法要么杀掉占用进程macOS/Linux上lsof -i:8080Windows上netstat -ano | findstr :8080要么在application.yml里换成8082端口。前端代理也需要同步改。5.2 启动顺序是门玄学正确的操作顺序是先启动MySQL服务 → 导入SQL脚本 → 启动后端SpringBoot → 启动前端Vue → 浏览器访问。顺序反了不是起不来就是启动后接口报错。后端启动成功的标志是控制台出现Tomcat started on port(s): 8080而不是BUILD SUCCESS。很多人看到BUILD SUCCESS就以为成功了其实是编译通过但还没启起来。然后前端在终端执行npm run serve出现App running at: http://localhost:8081就是成功。这两个标志记住判断“系统是否正常”就心里有底了。如果后端启动直接失败关键报错大多出现在Caused by那一行。看清具体是哪类错误再改找不到驱动类八成是Maven没拉全依赖连接被拒八成是MySQL没启动表不存在是脚本没导入或者库名对不上。解决顺序也有讲究先解决数据库再解决端口最后才看代码逻辑。5.3 功能自测清单别等到演示现场才手忙脚乱项目跑通后按照这套“用户动线”完整走一遍确认每个环节都正常用户注册一个新账号确认手机号和用户名校验生效。用新账号登录确认页面顶部状态从“未登录”变为用户昵称。首页点击任意商品进入详情页确认商品图、价格、库存显示正常。修改商品数量加入购物车确认购物车列表数量和总价正确。点击结算填写/选择收货地址提交订单确认生成订单号。模拟支付确认订单状态变为待发货。用管理员账号登录后台确认能查看这笔订单并可以发货。用户端刷新订单状态确认变为待收货。这套流程你最好走两遍一遍是登录状态正常的情况一遍是登录状态过期、强制刷新页面后的情况。很多毕设演示翻车就栽在“演示时一切正常但老师要求刷新页面后前端没带token接口401报错页面白屏”。提前把这些边界情况都测一遍是你答辩状态从容的关键。6. 把“成品”变成“自己的”二次开发与答辩讲法6.1 低成本改动就能有明显辨识度直接用原项目答辩最怕老师问“这个项目跟你有什么关系”。所以二次开发是几乎必须的。低成本又有辨识度的方向包括商品搜索功能后端加一个SELECT * FROM goods WHERE name LIKE %keyword%前端在导航栏加一个搜索框跳转到搜索结果页。整个改动工作量半天以内但项目立刻有了“搜索”模块。商品分类筛选给goods表加一个category字段首页将“全部商品”按T恤、衬衫、外套、裤装分区展示。后端加一个category参数即可前端做一个Tab切换。收货地址的增删改查原项目如果只有下单时选地址你可以把这个做成独立的“地址管理”页面这属于“补全用户账户体系”的顺理成章优化。图片上传后台新增商品时如果能支持本地上传图片上传到项目目录前端通过一个映射路径显示这个功能的工程意义比手动往SQL里塞Base64图片要大得多。6.2 答辩时怎么讲这套系统答辩陈述的核心逻辑是讲场景 → 讲技术 → 讲难点 → 讲验证顺着这条线讲老师会被你带着走。讲场景“我设计的是一个服装销售平台面向用户提供在线浏览、加购、下单等能力面向管理员提供商品上下架和订单处理能力。”讲技术拆分“前端用Vue Element UI搭建页面通过Axios与后端SpringBoot通信后端采用分层架构Controller负责路由分发Service承载业务逻辑Mapper对接MySQL数据库。”讲难点“整个系统最复杂的业务逻辑就是下单需要校验购物车、计算金额、扣减库存、生成订单明细、清空购物车还要保证并发下库存不超卖我通过数据库层的条件更新解决了这个问题。”讲验证“我完整走通了注册、登录、加购、下单、支付、发货、收货的完整流程并且测试了重复下单、库存不足等情况。”这四个点串起来一个清晰的系统叙事就成型了。老师听下来觉得你既懂原理又重验证基本不会再追问过深。6.3 二次开发时最容易翻车的三个点第一个坑是改代码时把前后端接口路径改岔了。前端axios请求路径和后端RequestMapping必须严格对齐少一个/或大小写不一致都是404排查时优先看Network面板标红的请求。第二个坑是数据库字段改了但实体类和Mapper没同步。给goods加了一个字段却忘了改Goods.java实体类运行起来就是Invalid column报错。对应关系要同步改这是Java Web最基本也最常犯的错误。第三个坑是改了前端组件后忘了重新构建。后端改完需要重启SpringBoot前端改完如果访问的是dist目录打包产物还得重新执行npm run build。用开发方式npm run serve时确实热更新不用管但如果部署到生产环境忘记构建这件事是爆炸级别翻车。你说它有多深不至于。但作为一套完整交付的毕设它在“跑通”“讲清”“可改”三维度上做得相当扎实。如果你现在手头正缺一个Java Web毕设项目这套源码是一个很值得花时间的底座。方向有了剩下的就是动手。一步步把数据库脚本导进去、把前后端跑起来、把每个接口读明白再用自己的思路改掉一部分代码这就是最稳的毕业设计打开方式。