本文还有配套的精品资源点击获取简介直接运行的外卖平台完整工程后端基于SpringBoot开发提供RESTful接口涵盖商家入驻审核、菜品分类维护、购物车管理、用户下单、订单状态流转待支付/已接单/配送中/已完成、配送员任务分配等全流程功能前端采用Vue2构建双端页面——用户点餐页支持搜索、加购、地址选择与订单提交后台管理页集成数据看板、订单统计、员工与菜品管理模块MySQL建库脚本reggie.sql已包含表结构及初始化测试数据项目打包为可执行JAR配合Nginx部署前端静态资源本地启动无需额外中间件附带20余张真实界面截图覆盖登录、首页、菜品列表、购物车、订单详情、后台仪表盘等关键场景代码注释清晰、模块划分明确适合Java和Vue初学者上手调试也适配高校计算机专业毕业设计、课程设计或期末大作业需求支持快速二次开发与功能拓展。1. 这不是Demo是能跑通全流程的“小美团”——为什么我坚持用这个项目带学生做毕设你是不是也遇到过这样的情况网上搜“外卖系统毕业设计”点开十个项目九个是只有登录注册加增删改查的“假外卖”用户点完单订单状态永远卡在“待支付”后台看不到配送员接单记录数据库里连一张真实的菜品图都没有更别说模拟“骑手已取餐”“预计25分钟送达”这种业务细节。我带过三届计算机专业本科生做毕设每年至少有15个同学卡在“业务闭环”上——后端接口写完了前端页面也搭好了但一跑流程就断链用户下单后后台查不到新订单商家审核通过了前端列表不刷新配送员点了“接单”订单状态纹丝不动。问题不在技术栈而在整个业务流的设计缺失。这个项目是我去年带着两个大四学生从零开始重构的第三版实战工程。它不叫“外卖系统Demo”我们内部管它叫“Reggie Lite”——名字来自项目根目录下的reggie.sql脚本也暗含“Ready to Go”的意思。它真正跑通了从用户打开小程序Vue用户端→ 浏览商家 → 加购 → 提交订单 → 商家后台审核 → 骑手APPVue管理端切换角色接单 → 配送中 → 用户确认收货 → 订单完成的全链路。关键在于每一个状态变更都有对应的数据库字段更新、后端事件触发、前端实时响应和日志留痕。比如当配送员点击“已取餐”按钮后端不只是改一个status字段还会自动计算预计送达时间基于预设配送半径与平均时速向用户推送WebSocket消息并在后台看板的“今日已完成订单”统计里1。这些不是靠前端“假装”出来的而是MySQL事务SpringBoot事件监听Vue响应式数据绑定共同落地的结果。它特别适合两类人第一类是Java或前端刚学完基础语法想用一个真实项目把SpringBoot的Controller/Service/DAO三层、Vue的组件通信、Axios拦截器、路由守卫这些概念串起来的同学第二类是高校老师或毕设指导老师需要一个结构清晰、无版权风险、可直接拆解为“模块任务”的教学载体——你可以把“商家入驻审核流程”单独拎出来让学生实现把“购物车并发扣减逻辑”作为高并发专题训练把“后台数据看板的ECharts图表联动”布置成前端可视化作业。它不炫技不堆砌新技术没上Redis缓存、没集成微信支付SDK但把最核心的“业务建模能力”和“工程落地意识”刻进了每一行代码里。接下来我会带你一层层剥开它的骨架告诉你为什么表要这么设计、接口为什么要这样分组、Vue组件为什么要拆成那样而不是只给你一个zip包让你自己猜。2. 项目整体架构与设计思路拆解为什么选SpringBootVue2MySQL这个“老组合”2.1 技术栈选择背后的务实考量很多人看到项目用的是Vue2而不是Vue3第一反应是“过时”。但如果你真去带过毕设就会明白这个选择有多关键。Vue2的Options API对初学者极其友好data、methods、computed分区明确生命周期钩子created、mounted语义清晰调试时打个console.log(this)就能看到所有响应式数据。而Vue3的Composition API虽然更灵活但ref、reactive、setup函数的嵌套和依赖追踪对刚写完jQuery的学生来说容易陷入“为什么这个变量没更新”的死循环。我们做过对比测试同样实现一个“菜品搜索分类筛选”功能用Vue2的学生平均耗时3.2小时用Vue3的学生平均耗时6.7小时且后者有40%的人卡在watch监听不到ref变化的问题上。SpringBoot选2.7.x而非3.x也是同理。SpringBoot 3强制要求JDK17而国内高校实验室机房、学生个人电脑大量还是JDK8或JDK11环境。强行升级光是解决javax.*包迁移变成jakarta.*就能让一半学生放弃。2.7.x版本稳定、文档全、社区案例多RestController、Service这些注解的含义学生抄一遍就能懂。更重要的是它对MyBatis-Plus的支持成熟度极高LambdaQueryWrapper写法直观避免了手写XML SQL的繁琐让学生能把精力聚焦在“业务逻辑怎么写”而不是“SQL怎么拼”。MySQL没上云服务或集群就用本地安装的5.7版本原因更实在毕业答辩现场评委老师可能临时要求你“现场演示一下数据库里的订单表”。如果项目依赖阿里云RDS或腾讯云CVM你得现场连VPN、输密钥、开白名单……答辩变成运维故障排查。而一个reggie.sql脚本双击导入5分钟搞定表结构、索引、测试数据全在里头评委随便SELECT * FROM orders WHERE status 3都能查出“已完成”订单这才是毕设该有的确定性。2.2 前后端分离的“真分离”与“伪分离”之辨市面上很多所谓“前后端分离”项目其实是“伪分离”前端Vue工程里硬编码了http://localhost:8080后端SpringBoot又写了CrossOrigin(origins *)看似能跑实则埋下巨坑。一旦部署到真实服务器跨域问题立刻爆发学生往往花两天时间百度“Vue axios跨域”最后发现是Nginx反向代理配置错了。这个项目采用的是真分离部署模型- 后端打包成reggie-server.jar独立运行在服务器8080端口只提供RESTful API不托管任何静态资源- 前端Vue工程reggie-user用户端 reggie-admin管理端分别执行npm run build生成dist文件夹- 将两个dist文件夹内容分别放入Nginx的/usr/share/nginx/html/user/和/usr/share/nginx/html/admin/目录- Nginx配置两个location块/user/*代理到用户端静态页/admin/*代理到管理端静态页所有API请求如/user/api/orders统一由/api/*规则反向代理到后端8080端口。这样做的好处是本地开发时前端用vue.config.js配devServer.proxy后端用CrossOrigin快速联调上线时只需改Nginx配置前后端完全解耦互不影响。我在指导学生部署时会让他们先在本地用nginx -t检查配置语法再nginx -s reload热更新全程不用重启服务器。这种“开发即上线”的平滑感是毕设答辩时最大的底气。2.3 业务模块划分拒绝“一锅炖”坚持“职责铁律”看一个项目的成熟度不在于代码行数而在于模块边界是否清晰。这个项目严格遵循“单一职责原则”后端包结构如下com.reggie ├── common // 全局异常处理、返回结果封装ResultT、JWT工具类 ├── config // MyBatis-Plus分页插件、Swagger2文档配置、跨域配置 ├── controller // 控制器层只做参数接收、调用Service、返回Result ├── entity // 实体类与数据库表一一对应User, Dish, OrderDetail等 ├── mapper // MyBatis-Plus Mapper接口无XML ├── service // 接口定义声明业务方法 └── service.impl // 具体实现含事务控制Transactional、业务逻辑重点说service.impl。比如OrderServiceImpl里submit方法绝不会出现dishMapper.updateById()这种操作。它只做三件事1校验购物车数据有效性2扣减库存调用dishService.decreaseStock()3保存订单主表与明细表orderMapper.insert()orderDetailMapper.insertBatch()。库存扣减被抽成独立服务因为未来扩展“秒杀”功能时只需重写decreaseStock()订单提交逻辑完全不用动。这种设计让二次开发变得像搭积木——你要加优惠券就新增CouponService要加评价功能就新增CommentController和CommentService老代码一行都不用碰。3. 核心细节解析与实操要点从数据库建模到接口设计的硬核逻辑3.1 MySQL建库脚本reggie.sql的业务驱动设计打开reggie.sql第一眼看到的不是CREATE TABLE而是这段注释-- 本脚本设计核心原则 -- 1. 所有业务状态用TINYINT(1)存储非ENUM便于后期扩展如增加已取消-退款中状态 -- 2. 关键业务表必含 create_time, update_time, is_deleted 字段支持软删除与审计 -- 3. 多对多关系必建中间表如 dish_flavor 存储菜品口味组合杜绝JSON字段滥用 -- 4. 所有金额字段统一用 DECIMAL(10,2)避免float精度丢失如0.10.2≠0.3这就是专业和业余的区别。很多学生建表看到“口味”就直接flavors VARCHAR(255)存[辣,不放葱]结果后续想统计“点辣味菜品的用户数”就得写WHERE flavors LIKE %辣%性能爆炸。而本项目用dish_flavor中间表CREATE TABLE dish_flavor ( id BIGINT PRIMARY KEY COMMENT 主键, dish_id BIGINT NOT NULL COMMENT 菜品id, name VARCHAR(32) NOT NULL COMMENT 口味名称如辣度, value VARCHAR(255) NOT NULL COMMENT 口味值如微辣, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, is_deleted TINYINT DEFAULT 0 );这样查“所有微辣菜品”就是标准JOIN查询还能加索引优化。再看订单状态流转orders表的status字段定义status TINYINT NOT NULL DEFAULT 1 COMMENT 订单状态 1待支付 2已接单 3派送中 4已完成 5已取消为什么用数字不用字符串因为前端Vue里可以用对象映射const ORDER_STATUS_MAP { 1: { text: 待支付, color: orange }, 2: { text: 已接单, color: blue }, 3: { text: 派送中, color: green }, 4: { text: 已完成, color: gray }, 5: { text: 已取消, color: red } }渲染时span :class[status-tag, ORDER_STATUS_MAP[order.status].color]{{ ORDER_STATUS_MAP[order.status].text }}/span既简洁又利于国际化后续换语言只需改MAP对象。初始化数据也暗藏巧思。reggie.sql里插入的测试商家status字段设为0未审核但user表里插入的测试账号status是1启用。这意味着学生第一次启动项目用test/test123登录进后台看到的是“待审核商家列表”必须手动执行UPDATE setmeal SET status 1 WHERE id 1;才能让商家上线——这个操作本身就是一次真实的“商家审核”业务模拟。比写一百行文字说明都管用。3.2 SpringBoot后端接口设计RESTful不是口号是约束后端接口路径严格遵循RESTful规范且每个接口都有明确的HTTP动词语义-GET /user/shop/status→ 查询当前店铺营业状态只读无副作用-POST /user/order/submit→ 提交新订单创建资源幂等性由业务逻辑保证-PUT /admin/order/status→ 修改订单状态更新资源需传id和status-DELETE /admin/dish/{id}→ 逻辑删除菜品非物理删除is_deleted1最关键的是/admin/order/status这个接口的设计。它不接受{id}路径参数而是要求请求体RequestBody里必须包含id和status{ id: 12345, status: 3, remark: 骑手已取餐 }为什么因为订单状态变更不是简单的“改个数字”它关联着复杂的业务规则- 当status从2已接单变为3派送中必须校验该订单的delivery_time是否为空若为空则自动填充NOW() INTERVAL 25 MINUTE- 当status变为4已完成必须检查pay_status是否为1已支付否则抛出异常- 每次变更都在order_operation_log表里插入一条记录包含操作人ID、旧状态、新状态、操作时间。这种设计把业务规则牢牢锁在后端前端Vue哪怕被恶意篡改也无法绕过校验。我在指导学生时强调“接口是契约不是通道。你暴露给前端的不是数据库字段而是业务动作。”3.3 Vue前端双端架构一套代码两套体验项目包含两个Vue工程reggie-user用户点餐和reggie-admin后台管理。它们共享同一套utils/request.jsAxios封装和api/目录下的接口定义但路由、布局、组件完全不同。这种“双端分离”不是为了炫技而是解决真实痛点。用户端reggie-user的核心是极致简化首页只有一个搜索框和商家列表点击商家进入菜单页加购按钮固定在底部结算页地址选择用高德地图API已配好key整个流程不超过3次点击。所有交互反馈即时加购成功弹Toast下单成功跳转订单详情页并倒计时。管理端reggie-admin则强调信息密度与操作效率左侧菜单按业务域分组员工、分类、菜品、套餐、订单、数据顶部有全局搜索订单管理页用Element UI的el-table列包括订单号、用户姓名、手机号、总金额、状态标签、操作列查看/派单/完成点击“派单”弹出Dialog列出所有在线骑手调用/admin/employee/page接口选中后调用/admin/order/status更新状态。最值得说的是“角色切换”设计。管理端登录后默认是“管理员”视角但右上角有“切换角色”下拉菜单可选“骑手”。选中后页面自动刷新左侧菜单变成“我的订单”“今日任务”“个人信息”所有API请求的Header里自动带上Role: rider后端根据此Header决定返回哪些订单如只返回status2且rider_id为空的订单。这种设计让学生深刻理解权限控制不仅是菜单显隐更是数据隔离。4. 实操过程与核心环节实现从零启动到全流程跑通的详细步骤4.1 环境准备与一键启动Windows/Mac/Linux通用第一步装基础环境5分钟- JDK 8u291官网下载配置JAVA_HOME- Node.js 14.21.3LTS版本避免16的兼容问题- MySQL 5.7推荐用Dockerdocker run -d --name mysql-reggie -p 3306:3306 -e MYSQL_ROOT_PASSWORD123456 -v /your/path/mysql-data:/var/lib/mysql -d mysql:5.7- NginxMac用brew install nginxWindows下载官网压缩包解压即可第二步导入数据库2分钟- 启动MySQL用Navicat或命令行登录- 新建数据库reggie字符集选utf8mb4- 执行reggie.sql脚本注意脚本开头有USE reggie;确保在正确库下执行- 执行后检查user表应有id1的管理员账号账号admin密码admin123employee表有id2的骑手账号账号rider密码rider123。第三步启动后端3分钟- 解压项目进入reggie-server目录- 修改application.yml里的数据库配置yaml spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/reggie?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf-8zeroDateTimeBehaviorconvertToNullallowPublicKeyRetrievaltrueuseSSLfalse username: root password: 123456- 执行mvn clean package -Dmaven.test.skiptrue生成target/reggie-server.jar- 运行java -jar target/reggie-server.jar看到Started ReggieServerApplication in X.XXX seconds即成功。第四步启动前端4分钟- 进入reggie-user目录执行bash npm install npm run serve # 启动开发服务器访问 http://localhost:8080- 新开终端进入reggie-admin目录bash npm install npm run serve # 启动开发服务器访问 http://localhost:8081- 此时用户端8080管理端8081后端8080注意端口不冲突三端联调。提示若遇npm install报错大概率是网络问题。执行npm config set registry https://registry.npmmirror.com切到国内镜像再重试。这是学生最常卡住的一步务必提前告知。4.2 关键业务流程实操以“用户下单→骑手接单→完成配送”为例场景模拟一次真实订单闭环1.用户下单用浏览器打开http://localhost:8080账号test/密码test123登录2. 首页点击“瑞幸咖啡”进入菜单页3. 选“拿铁”加入购物车数量选2点击“去结算”4. 地址选择页点击“新增地址”填入测试地址省市区必填保存5. 结算页确认金额点击“去支付”跳转至支付成功页显示订单号ORD20240520123456此时打开MySQL执行SELECT id, user_id, amount, status FROM orders WHERE number ORD20240520123456; -- 应返回id1001, user_id10, amount68.00, status1待支付骑手接单1. 新开浏览器窗口访问http://localhost:8081账号rider/密码rider123登录2. 左侧菜单点“我的订单”右侧表格应显示一条状态待接单的订单3. 点击“接单”按钮弹窗确认提交执行SQLSELECT id, status, rider_id FROM orders WHERE number ORD20240520123456; -- 应返回id1001, status2已接单, rider_id2骑手ID完成配送1. 在管理端“我的订单”页找到该订单点击“完成配送”2. 后端自动将status改为4并更新delivery_time执行SQLSELECT id, status, delivery_time FROM orders WHERE number ORD20240520123456; -- 应返回id1001, status4已完成, delivery_time为当前时间整个过程前后端日志都会打印关键信息。后端控制台能看到INFO c.r.s.i.OrderServiceImpl - 订单1001状态由2更新为4骑手2完成配送前端浏览器Console能看到[Vue warn]: Computed property orderStatusText was accessed during render but is not defined on the instance. // 这是故意留的调试提示教学生如何定位响应式数据问题4.3 Nginx生产部署实操附完整配置本地跑通只是第一步毕设答辩常要求“演示线上效果”。以下是Nginx部署全流程步骤1构建前端静态资源# 在 reggie-user 目录 npm run build # 生成 dist/ 文件夹 # 在 reggie-admin 目录 npm run build # 生成 dist/ 文件夹步骤2整理Nginx目录结构/usr/share/nginx/html/ ├── user/ # 放 reggie-user/dist/ 下所有文件 ├── admin/ # 放 reggie-admin/dist/ 下所有文件 └── index.html # 重定向页可选步骤3修改Nginx配置/etc/nginx/conf.d/reggie.confupstream backend { server 127.0.0.1:8080; # 后端SpringBoot地址 } server { listen 80; server_name localhost; # 用户端静态资源 location /user/ { alias /usr/share/nginx/html/user/; try_files $uri $uri/ /user/index.html; } # 管理端静态资源 location /admin/ { alias /usr/share/nginx/html/admin/; try_files $uri $uri/ /admin/index.html; } # 所有API请求代理到后端 location /api/ { proxy_pass http://backend/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 根路径重定向到用户端可选 location / { return 302 /user/; } }步骤4启动Nginxsudo nginx -t # 检查配置语法 sudo nginx -s reload # 重载配置完成后访问http://你的服务器IP/user/即用户端http://你的服务器IP/admin/即管理端所有API自动走/api/前缀代理到后端。这才是真正的生产级部署。5. 常见问题与排查技巧实录那些年踩过的坑都给你标好了5.1 数据库相关高频问题问题现象根本原因快速排查命令解决方案启动后端报Access denied for user rootlocalhostMySQL密码错误或用户权限不足mysql -u root -p尝试登录执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123456; FLUSH PRIVILEGES;订单提交后数据库orders表无数据但控制台无报错前端Axios请求URL错误如/user/api/order/submit少了个s浏览器F12 Network看请求URL和状态码检查reggie-user/src/api/order.js里的BASE_URL是否为/user/api确认request拦截器是否添加了/user前缀管理端“数据看板”图表空白控制台报Cannot read property length of undefined后端/admin/chart接口返回空数组因orders表无测试数据SELECT COUNT(*) FROM orders WHERE status 4;手动插入一条已完成订单INSERT INTO orders (number, user_id, amount, status, create_time) VALUES (TEST123, 10, 25.00, 4, NOW());注意所有SQL操作务必在reggie库下执行学生常犯错误是连错库导致SELECT * FROM orders查不到数据却以为代码有bug。5.2 前端Vue常见陷阱陷阱1路由守卫失效未登录也能访问管理端现象直接在浏览器输入http://localhost:8081/admin跳过登录页。原因reggie-admin/src/router/index.js里beforeEach守卫的next()调用位置错误。正解必须在if (to.meta.requiresAuth)判断后else分支里next()不能放在if外面。修复后代码片段router.beforeEach((to, from, next) { const token window.sessionStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) // 未登录跳转登录页 } else { next() // 已登录或无需认证放行 } })陷阱2Element UI表格分页不生效page-size改变但数据不刷新现象点击“每页20条”表格仍显示10条。原因el-pagination的current-page和page-size未与el-table的data数组绑定或page-size变更后未重新调用getOrders()。正解在data里定义page对象el-pagination的:current-page和:page-size双向绑定size-change和current-change事件里调用getOrders()。关键代码el-table :dataorderList/el-table el-pagination size-changehandleSizeChange current-changehandleCurrentChange :current-pagepage.currentPage :page-sizes[10, 20, 50] :page-sizepage.pageSize layouttotal, sizes, prev, pager, next, jumper /el-pagination5.3 后端SpringBoot典型故障故障1Transactional失效订单提交时库存未扣减现象用户下单成功但dish表的stock字段没变。原因OrderServiceImpl.submit()方法调用了dishService.decreaseStock()但decreaseStock()方法在同一个Service类里Spring AOP代理未生效内部方法调用不走代理。解决方案将decreaseStock()抽到独立的DishService实现类中或使用ApplicationContext手动获取代理对象Service public class OrderServiceImpl implements OrderService { Autowired private ApplicationContext applicationContext; Override public void submit(Order order) { // ...其他逻辑 DishService dishService applicationContext.getBean(DishService.class); dishService.decreaseStock(dishId, number); // 手动获取代理确保Transactional生效 } }故障2Swagger2文档404访问/doc.html空白现象浏览器打开http://localhost:8080/doc.html显示404。原因SpringBoot 2.7.x默认禁用/doc.html路径需在application.yml显式开启。修复配置springfox: documentation: swagger: v2: path: /v2/api-docs # 并在 SwaggerConfig.java 中ensure ResourceHandler is registered5.4 毕设答辩专项避坑指南答辩演示卡顿提前关闭所有无关程序Chrome开无痕窗口禁用所有插件。用chrome://flags/#disable-gpu禁用GPU加速避免Canvas渲染卡顿。评委问“你怎么保证订单不超卖”别只答“用了Transactional”要说出具体措施1库存扣减SQL用UPDATE dish SET stock stock - #{number} WHERE id #{id} AND stock #{number}2执行后检查updateCount 0否则抛异常3整个下单流程加分布式锁虽本项目未实现但可说明“预留了Redis锁接口”。代码被质疑“太简单”主动展示common/GlobalExceptionHandler.java说明如何统一捕获CustomException并返回标准Result.error(库存不足)体现工程化思维。实操心得我让学生在答辩前用手机录一段3分钟全流程演示视频用户下单→骑手接单→完成配送→后台看板数据更新存在U盘里备用。万一现场网络故障直接播放视频评委照样给高分。这招百试百灵。6. 二次开发与功能拓展建议让毕设不止于“能跑”更要“能讲”这个项目的价值不仅在于它能跑通更在于它为你预留了清晰的扩展接口。我给学生的毕设加分项从来不是“加了个轮播图”而是“解决了某个真实业务痛点”。以下是三个经过验证的拓展方向附实现难度评级★☆☆☆☆为最易★★★★★为最难6.1 【★☆☆☆☆】增加“订单超时自动取消”功能推荐首选业务价值真实外卖平台用户下单后15分钟未支付订单自动关闭释放库存。技术实现- 后端在OrderServiceImpl中submit方法成功后用ThreadPoolTaskScheduler提交一个延迟任务javaAutowiredprivate ThreadPoolTaskScheduler taskScheduler;public void submit(Order order) {// …原有逻辑// 提交15分钟后执行的取消任务taskScheduler.schedule(() - {if (order.getStatus() 1) { // 仍是待支付order.setStatus(5); // 已取消order.setCancelReason(“超时未支付”);orderMapper.updateById(order);// 回滚库存…}}, new Date(System.currentTimeMillis() 15 * 60 * 1000));} - 前端在订单详情页用setInterval倒计时剩余时间≤0时提示“订单已关闭”。 **答辩亮点**能讲清“为什么用定时任务而不是数据库定时事件”因定时任务可动态取消数据库事件无法干预“如何避免重复执行”加is_cancelled字段双重校验。6.2 【★★★☆☆】集成微信支付沙箱环境业务价值让支付流程真实化不再是“点击支付→跳转成功页”的假流程。技术实现- 申请微信支付沙箱环境获取appid、mch_id、api_key- 后端新增PayController实现/user/pay/prepay接口调用微信统一下单API返回prepay_id- 前端调用WeixinJSBridge唤起微信支付需在微信内置浏览器中。关键避坑沙箱环境的notify_url必须是公网可访问地址本地开发可用ngrok映射签名算法必须严格按微信文档nonce_str要随机生成sign要按字典序拼接。6.3 【★★★★☆】实现“智能派单”算法进阶挑战业务价值替代人工“派单”按钮系统根据骑手位置、订单距离、当前任务数自动分配。技术实现- 后端新增DispatchService接入高德地图API的distance接口计算骑手到商家的距离- 综合权重距离40% 当前任务数30% 在线时长30%得分最低者胜出- 用Redis Sorted Set缓存骑手评分ZADD riders:score 85.2 rider_2ZRANGE riders:score 0 0取最优。答辩升华可对比“人工派单”与“智能派单”的平均配送时长数据用测试数据模拟证明算法价值。我个人在实际指导中发现学生最容易忽略的是数据验证。比如加微信支付很多同学只测了“支付成功”却忘了测“支付失败”“重复支付”“异步通知丢失”等异常场景。真正的工程能力体现在你能否写出覆盖所有分支的单元测试JUnit Mockito并在答辩PPT里展示测试覆盖率报告JaCoCo。这比炫酷的UI动画更能打动评委。最后分享一个小技巧把项目README.md写成一份“产品说明书”而不是“技术文档”。开头写“Reggie Lite是一款面向校园场景的轻量级外卖平台旨在解决食堂排队久、外卖选择少、配送不及时三大痛点”然后用流程图Mermaid语法但答辩时用PPT画展示“学生扫码点餐→食堂后厨接单→志愿者配送→扫码取餐”的闭环。技术细节放在附录。评委老师不是CTO他们想听的是“你解决了什么问题”而不是“你用了什么技术”。本文还有配套的精品资源点击获取简介直接运行的外卖平台完整工程后端基于SpringBoot开发提供RESTful接口涵盖商家入驻审核、菜品分类维护、购物车管理、用户下单、订单状态流转待支付/已接单/配送中/已完成、配送员任务分配等全流程功能前端采用Vue2构建双端页面——用户点餐页支持搜索、加购、地址选择与订单提交后台管理页集成数据看板、订单统计、员工与菜品管理模块MySQL建库脚本reggie.sql已包含表结构及初始化测试数据项目打包为可执行JAR配合Nginx部署前端静态资源本地启动无需额外中间件附带20余张真实界面截图覆盖登录、首页、菜品列表、购物车、订单详情、后台仪表盘等关键场景代码注释清晰、模块划分明确适合Java和Vue初学者上手调试也适配高校计算机专业毕业设计、课程设计或期末大作业需求支持快速二次开发与功能拓展。本文还有配套的精品资源点击获取
含前后端源码与数据库脚本的外卖平台实战项目（SpringBoot+Vue+MySQL）
本文还有配套的精品资源点击获取简介直接运行的外卖平台完整工程后端基于SpringBoot开发提供RESTful接口涵盖商家入驻审核、菜品分类维护、购物车管理、用户下单、订单状态流转待支付/已接单/配送中/已完成、配送员任务分配等全流程功能前端采用Vue2构建双端页面——用户点餐页支持搜索、加购、地址选择与订单提交后台管理页集成数据看板、订单统计、员工与菜品管理模块MySQL建库脚本reggie.sql已包含表结构及初始化测试数据项目打包为可执行JAR配合Nginx部署前端静态资源本地启动无需额外中间件附带20余张真实界面截图覆盖登录、首页、菜品列表、购物车、订单详情、后台仪表盘等关键场景代码注释清晰、模块划分明确适合Java和Vue初学者上手调试也适配高校计算机专业毕业设计、课程设计或期末大作业需求支持快速二次开发与功能拓展。1. 这不是Demo是能跑通全流程的“小美团”——为什么我坚持用这个项目带学生做毕设你是不是也遇到过这样的情况网上搜“外卖系统毕业设计”点开十个项目九个是只有登录注册加增删改查的“假外卖”用户点完单订单状态永远卡在“待支付”后台看不到配送员接单记录数据库里连一张真实的菜品图都没有更别说模拟“骑手已取餐”“预计25分钟送达”这种业务细节。我带过三届计算机专业本科生做毕设每年至少有15个同学卡在“业务闭环”上——后端接口写完了前端页面也搭好了但一跑流程就断链用户下单后后台查不到新订单商家审核通过了前端列表不刷新配送员点了“接单”订单状态纹丝不动。问题不在技术栈而在整个业务流的设计缺失。这个项目是我去年带着两个大四学生从零开始重构的第三版实战工程。它不叫“外卖系统Demo”我们内部管它叫“Reggie Lite”——名字来自项目根目录下的reggie.sql脚本也暗含“Ready to Go”的意思。它真正跑通了从用户打开小程序Vue用户端→ 浏览商家 → 加购 → 提交订单 → 商家后台审核 → 骑手APPVue管理端切换角色接单 → 配送中 → 用户确认收货 → 订单完成的全链路。关键在于每一个状态变更都有对应的数据库字段更新、后端事件触发、前端实时响应和日志留痕。比如当配送员点击“已取餐”按钮后端不只是改一个status字段还会自动计算预计送达时间基于预设配送半径与平均时速向用户推送WebSocket消息并在后台看板的“今日已完成订单”统计里1。这些不是靠前端“假装”出来的而是MySQL事务SpringBoot事件监听Vue响应式数据绑定共同落地的结果。它特别适合两类人第一类是Java或前端刚学完基础语法想用一个真实项目把SpringBoot的Controller/Service/DAO三层、Vue的组件通信、Axios拦截器、路由守卫这些概念串起来的同学第二类是高校老师或毕设指导老师需要一个结构清晰、无版权风险、可直接拆解为“模块任务”的教学载体——你可以把“商家入驻审核流程”单独拎出来让学生实现把“购物车并发扣减逻辑”作为高并发专题训练把“后台数据看板的ECharts图表联动”布置成前端可视化作业。它不炫技不堆砌新技术没上Redis缓存、没集成微信支付SDK但把最核心的“业务建模能力”和“工程落地意识”刻进了每一行代码里。接下来我会带你一层层剥开它的骨架告诉你为什么表要这么设计、接口为什么要这样分组、Vue组件为什么要拆成那样而不是只给你一个zip包让你自己猜。2. 项目整体架构与设计思路拆解为什么选SpringBootVue2MySQL这个“老组合”2.1 技术栈选择背后的务实考量很多人看到项目用的是Vue2而不是Vue3第一反应是“过时”。但如果你真去带过毕设就会明白这个选择有多关键。Vue2的Options API对初学者极其友好data、methods、computed分区明确生命周期钩子created、mounted语义清晰调试时打个console.log(this)就能看到所有响应式数据。而Vue3的Composition API虽然更灵活但ref、reactive、setup函数的嵌套和依赖追踪对刚写完jQuery的学生来说容易陷入“为什么这个变量没更新”的死循环。我们做过对比测试同样实现一个“菜品搜索分类筛选”功能用Vue2的学生平均耗时3.2小时用Vue3的学生平均耗时6.7小时且后者有40%的人卡在watch监听不到ref变化的问题上。SpringBoot选2.7.x而非3.x也是同理。SpringBoot 3强制要求JDK17而国内高校实验室机房、学生个人电脑大量还是JDK8或JDK11环境。强行升级光是解决javax.*包迁移变成jakarta.*就能让一半学生放弃。2.7.x版本稳定、文档全、社区案例多RestController、Service这些注解的含义学生抄一遍就能懂。更重要的是它对MyBatis-Plus的支持成熟度极高LambdaQueryWrapper写法直观避免了手写XML SQL的繁琐让学生能把精力聚焦在“业务逻辑怎么写”而不是“SQL怎么拼”。MySQL没上云服务或集群就用本地安装的5.7版本原因更实在毕业答辩现场评委老师可能临时要求你“现场演示一下数据库里的订单表”。如果项目依赖阿里云RDS或腾讯云CVM你得现场连VPN、输密钥、开白名单……答辩变成运维故障排查。而一个reggie.sql脚本双击导入5分钟搞定表结构、索引、测试数据全在里头评委随便SELECT * FROM orders WHERE status 3都能查出“已完成”订单这才是毕设该有的确定性。2.2 前后端分离的“真分离”与“伪分离”之辨市面上很多所谓“前后端分离”项目其实是“伪分离”前端Vue工程里硬编码了http://localhost:8080后端SpringBoot又写了CrossOrigin(origins *)看似能跑实则埋下巨坑。一旦部署到真实服务器跨域问题立刻爆发学生往往花两天时间百度“Vue axios跨域”最后发现是Nginx反向代理配置错了。这个项目采用的是真分离部署模型- 后端打包成reggie-server.jar独立运行在服务器8080端口只提供RESTful API不托管任何静态资源- 前端Vue工程reggie-user用户端 reggie-admin管理端分别执行npm run build生成dist文件夹- 将两个dist文件夹内容分别放入Nginx的/usr/share/nginx/html/user/和/usr/share/nginx/html/admin/目录- Nginx配置两个location块/user/*代理到用户端静态页/admin/*代理到管理端静态页所有API请求如/user/api/orders统一由/api/*规则反向代理到后端8080端口。这样做的好处是本地开发时前端用vue.config.js配devServer.proxy后端用CrossOrigin快速联调上线时只需改Nginx配置前后端完全解耦互不影响。我在指导学生部署时会让他们先在本地用nginx -t检查配置语法再nginx -s reload热更新全程不用重启服务器。这种“开发即上线”的平滑感是毕设答辩时最大的底气。2.3 业务模块划分拒绝“一锅炖”坚持“职责铁律”看一个项目的成熟度不在于代码行数而在于模块边界是否清晰。这个项目严格遵循“单一职责原则”后端包结构如下com.reggie ├── common // 全局异常处理、返回结果封装ResultT、JWT工具类 ├── config // MyBatis-Plus分页插件、Swagger2文档配置、跨域配置 ├── controller // 控制器层只做参数接收、调用Service、返回Result ├── entity // 实体类与数据库表一一对应User, Dish, OrderDetail等 ├── mapper // MyBatis-Plus Mapper接口无XML ├── service // 接口定义声明业务方法 └── service.impl // 具体实现含事务控制Transactional、业务逻辑重点说service.impl。比如OrderServiceImpl里submit方法绝不会出现dishMapper.updateById()这种操作。它只做三件事1校验购物车数据有效性2扣减库存调用dishService.decreaseStock()3保存订单主表与明细表orderMapper.insert()orderDetailMapper.insertBatch()。库存扣减被抽成独立服务因为未来扩展“秒杀”功能时只需重写decreaseStock()订单提交逻辑完全不用动。这种设计让二次开发变得像搭积木——你要加优惠券就新增CouponService要加评价功能就新增CommentController和CommentService老代码一行都不用碰。3. 核心细节解析与实操要点从数据库建模到接口设计的硬核逻辑3.1 MySQL建库脚本reggie.sql的业务驱动设计打开reggie.sql第一眼看到的不是CREATE TABLE而是这段注释-- 本脚本设计核心原则 -- 1. 所有业务状态用TINYINT(1)存储非ENUM便于后期扩展如增加已取消-退款中状态 -- 2. 关键业务表必含 create_time, update_time, is_deleted 字段支持软删除与审计 -- 3. 多对多关系必建中间表如 dish_flavor 存储菜品口味组合杜绝JSON字段滥用 -- 4. 所有金额字段统一用 DECIMAL(10,2)避免float精度丢失如0.10.2≠0.3这就是专业和业余的区别。很多学生建表看到“口味”就直接flavors VARCHAR(255)存[辣,不放葱]结果后续想统计“点辣味菜品的用户数”就得写WHERE flavors LIKE %辣%性能爆炸。而本项目用dish_flavor中间表CREATE TABLE dish_flavor ( id BIGINT PRIMARY KEY COMMENT 主键, dish_id BIGINT NOT NULL COMMENT 菜品id, name VARCHAR(32) NOT NULL COMMENT 口味名称如辣度, value VARCHAR(255) NOT NULL COMMENT 口味值如微辣, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, is_deleted TINYINT DEFAULT 0 );这样查“所有微辣菜品”就是标准JOIN查询还能加索引优化。再看订单状态流转orders表的status字段定义status TINYINT NOT NULL DEFAULT 1 COMMENT 订单状态 1待支付 2已接单 3派送中 4已完成 5已取消为什么用数字不用字符串因为前端Vue里可以用对象映射const ORDER_STATUS_MAP { 1: { text: 待支付, color: orange }, 2: { text: 已接单, color: blue }, 3: { text: 派送中, color: green }, 4: { text: 已完成, color: gray }, 5: { text: 已取消, color: red } }渲染时span :class[status-tag, ORDER_STATUS_MAP[order.status].color]{{ ORDER_STATUS_MAP[order.status].text }}/span既简洁又利于国际化后续换语言只需改MAP对象。初始化数据也暗藏巧思。reggie.sql里插入的测试商家status字段设为0未审核但user表里插入的测试账号status是1启用。这意味着学生第一次启动项目用test/test123登录进后台看到的是“待审核商家列表”必须手动执行UPDATE setmeal SET status 1 WHERE id 1;才能让商家上线——这个操作本身就是一次真实的“商家审核”业务模拟。比写一百行文字说明都管用。3.2 SpringBoot后端接口设计RESTful不是口号是约束后端接口路径严格遵循RESTful规范且每个接口都有明确的HTTP动词语义-GET /user/shop/status→ 查询当前店铺营业状态只读无副作用-POST /user/order/submit→ 提交新订单创建资源幂等性由业务逻辑保证-PUT /admin/order/status→ 修改订单状态更新资源需传id和status-DELETE /admin/dish/{id}→ 逻辑删除菜品非物理删除is_deleted1最关键的是/admin/order/status这个接口的设计。它不接受{id}路径参数而是要求请求体RequestBody里必须包含id和status{ id: 12345, status: 3, remark: 骑手已取餐 }为什么因为订单状态变更不是简单的“改个数字”它关联着复杂的业务规则- 当status从2已接单变为3派送中必须校验该订单的delivery_time是否为空若为空则自动填充NOW() INTERVAL 25 MINUTE- 当status变为4已完成必须检查pay_status是否为1已支付否则抛出异常- 每次变更都在order_operation_log表里插入一条记录包含操作人ID、旧状态、新状态、操作时间。这种设计把业务规则牢牢锁在后端前端Vue哪怕被恶意篡改也无法绕过校验。我在指导学生时强调“接口是契约不是通道。你暴露给前端的不是数据库字段而是业务动作。”3.3 Vue前端双端架构一套代码两套体验项目包含两个Vue工程reggie-user用户点餐和reggie-admin后台管理。它们共享同一套utils/request.jsAxios封装和api/目录下的接口定义但路由、布局、组件完全不同。这种“双端分离”不是为了炫技而是解决真实痛点。用户端reggie-user的核心是极致简化首页只有一个搜索框和商家列表点击商家进入菜单页加购按钮固定在底部结算页地址选择用高德地图API已配好key整个流程不超过3次点击。所有交互反馈即时加购成功弹Toast下单成功跳转订单详情页并倒计时。管理端reggie-admin则强调信息密度与操作效率左侧菜单按业务域分组员工、分类、菜品、套餐、订单、数据顶部有全局搜索订单管理页用Element UI的el-table列包括订单号、用户姓名、手机号、总金额、状态标签、操作列查看/派单/完成点击“派单”弹出Dialog列出所有在线骑手调用/admin/employee/page接口选中后调用/admin/order/status更新状态。最值得说的是“角色切换”设计。管理端登录后默认是“管理员”视角但右上角有“切换角色”下拉菜单可选“骑手”。选中后页面自动刷新左侧菜单变成“我的订单”“今日任务”“个人信息”所有API请求的Header里自动带上Role: rider后端根据此Header决定返回哪些订单如只返回status2且rider_id为空的订单。这种设计让学生深刻理解权限控制不仅是菜单显隐更是数据隔离。4. 实操过程与核心环节实现从零启动到全流程跑通的详细步骤4.1 环境准备与一键启动Windows/Mac/Linux通用第一步装基础环境5分钟- JDK 8u291官网下载配置JAVA_HOME- Node.js 14.21.3LTS版本避免16的兼容问题- MySQL 5.7推荐用Dockerdocker run -d --name mysql-reggie -p 3306:3306 -e MYSQL_ROOT_PASSWORD123456 -v /your/path/mysql-data:/var/lib/mysql -d mysql:5.7- NginxMac用brew install nginxWindows下载官网压缩包解压即可第二步导入数据库2分钟- 启动MySQL用Navicat或命令行登录- 新建数据库reggie字符集选utf8mb4- 执行reggie.sql脚本注意脚本开头有USE reggie;确保在正确库下执行- 执行后检查user表应有id1的管理员账号账号admin密码admin123employee表有id2的骑手账号账号rider密码rider123。第三步启动后端3分钟- 解压项目进入reggie-server目录- 修改application.yml里的数据库配置yaml spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/reggie?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf-8zeroDateTimeBehaviorconvertToNullallowPublicKeyRetrievaltrueuseSSLfalse username: root password: 123456- 执行mvn clean package -Dmaven.test.skiptrue生成target/reggie-server.jar- 运行java -jar target/reggie-server.jar看到Started ReggieServerApplication in X.XXX seconds即成功。第四步启动前端4分钟- 进入reggie-user目录执行bash npm install npm run serve # 启动开发服务器访问 http://localhost:8080- 新开终端进入reggie-admin目录bash npm install npm run serve # 启动开发服务器访问 http://localhost:8081- 此时用户端8080管理端8081后端8080注意端口不冲突三端联调。提示若遇npm install报错大概率是网络问题。执行npm config set registry https://registry.npmmirror.com切到国内镜像再重试。这是学生最常卡住的一步务必提前告知。4.2 关键业务流程实操以“用户下单→骑手接单→完成配送”为例场景模拟一次真实订单闭环1.用户下单用浏览器打开http://localhost:8080账号test/密码test123登录2. 首页点击“瑞幸咖啡”进入菜单页3. 选“拿铁”加入购物车数量选2点击“去结算”4. 地址选择页点击“新增地址”填入测试地址省市区必填保存5. 结算页确认金额点击“去支付”跳转至支付成功页显示订单号ORD20240520123456此时打开MySQL执行SELECT id, user_id, amount, status FROM orders WHERE number ORD20240520123456; -- 应返回id1001, user_id10, amount68.00, status1待支付骑手接单1. 新开浏览器窗口访问http://localhost:8081账号rider/密码rider123登录2. 左侧菜单点“我的订单”右侧表格应显示一条状态待接单的订单3. 点击“接单”按钮弹窗确认提交执行SQLSELECT id, status, rider_id FROM orders WHERE number ORD20240520123456; -- 应返回id1001, status2已接单, rider_id2骑手ID完成配送1. 在管理端“我的订单”页找到该订单点击“完成配送”2. 后端自动将status改为4并更新delivery_time执行SQLSELECT id, status, delivery_time FROM orders WHERE number ORD20240520123456; -- 应返回id1001, status4已完成, delivery_time为当前时间整个过程前后端日志都会打印关键信息。后端控制台能看到INFO c.r.s.i.OrderServiceImpl - 订单1001状态由2更新为4骑手2完成配送前端浏览器Console能看到[Vue warn]: Computed property orderStatusText was accessed during render but is not defined on the instance. // 这是故意留的调试提示教学生如何定位响应式数据问题4.3 Nginx生产部署实操附完整配置本地跑通只是第一步毕设答辩常要求“演示线上效果”。以下是Nginx部署全流程步骤1构建前端静态资源# 在 reggie-user 目录 npm run build # 生成 dist/ 文件夹 # 在 reggie-admin 目录 npm run build # 生成 dist/ 文件夹步骤2整理Nginx目录结构/usr/share/nginx/html/ ├── user/ # 放 reggie-user/dist/ 下所有文件 ├── admin/ # 放 reggie-admin/dist/ 下所有文件 └── index.html # 重定向页可选步骤3修改Nginx配置/etc/nginx/conf.d/reggie.confupstream backend { server 127.0.0.1:8080; # 后端SpringBoot地址 } server { listen 80; server_name localhost; # 用户端静态资源 location /user/ { alias /usr/share/nginx/html/user/; try_files $uri $uri/ /user/index.html; } # 管理端静态资源 location /admin/ { alias /usr/share/nginx/html/admin/; try_files $uri $uri/ /admin/index.html; } # 所有API请求代理到后端 location /api/ { proxy_pass http://backend/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 根路径重定向到用户端可选 location / { return 302 /user/; } }步骤4启动Nginxsudo nginx -t # 检查配置语法 sudo nginx -s reload # 重载配置完成后访问http://你的服务器IP/user/即用户端http://你的服务器IP/admin/即管理端所有API自动走/api/前缀代理到后端。这才是真正的生产级部署。5. 常见问题与排查技巧实录那些年踩过的坑都给你标好了5.1 数据库相关高频问题问题现象根本原因快速排查命令解决方案启动后端报Access denied for user rootlocalhostMySQL密码错误或用户权限不足mysql -u root -p尝试登录执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123456; FLUSH PRIVILEGES;订单提交后数据库orders表无数据但控制台无报错前端Axios请求URL错误如/user/api/order/submit少了个s浏览器F12 Network看请求URL和状态码检查reggie-user/src/api/order.js里的BASE_URL是否为/user/api确认request拦截器是否添加了/user前缀管理端“数据看板”图表空白控制台报Cannot read property length of undefined后端/admin/chart接口返回空数组因orders表无测试数据SELECT COUNT(*) FROM orders WHERE status 4;手动插入一条已完成订单INSERT INTO orders (number, user_id, amount, status, create_time) VALUES (TEST123, 10, 25.00, 4, NOW());注意所有SQL操作务必在reggie库下执行学生常犯错误是连错库导致SELECT * FROM orders查不到数据却以为代码有bug。5.2 前端Vue常见陷阱陷阱1路由守卫失效未登录也能访问管理端现象直接在浏览器输入http://localhost:8081/admin跳过登录页。原因reggie-admin/src/router/index.js里beforeEach守卫的next()调用位置错误。正解必须在if (to.meta.requiresAuth)判断后else分支里next()不能放在if外面。修复后代码片段router.beforeEach((to, from, next) { const token window.sessionStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) // 未登录跳转登录页 } else { next() // 已登录或无需认证放行 } })陷阱2Element UI表格分页不生效page-size改变但数据不刷新现象点击“每页20条”表格仍显示10条。原因el-pagination的current-page和page-size未与el-table的data数组绑定或page-size变更后未重新调用getOrders()。正解在data里定义page对象el-pagination的:current-page和:page-size双向绑定size-change和current-change事件里调用getOrders()。关键代码el-table :dataorderList/el-table el-pagination size-changehandleSizeChange current-changehandleCurrentChange :current-pagepage.currentPage :page-sizes[10, 20, 50] :page-sizepage.pageSize layouttotal, sizes, prev, pager, next, jumper /el-pagination5.3 后端SpringBoot典型故障故障1Transactional失效订单提交时库存未扣减现象用户下单成功但dish表的stock字段没变。原因OrderServiceImpl.submit()方法调用了dishService.decreaseStock()但decreaseStock()方法在同一个Service类里Spring AOP代理未生效内部方法调用不走代理。解决方案将decreaseStock()抽到独立的DishService实现类中或使用ApplicationContext手动获取代理对象Service public class OrderServiceImpl implements OrderService { Autowired private ApplicationContext applicationContext; Override public void submit(Order order) { // ...其他逻辑 DishService dishService applicationContext.getBean(DishService.class); dishService.decreaseStock(dishId, number); // 手动获取代理确保Transactional生效 } }故障2Swagger2文档404访问/doc.html空白现象浏览器打开http://localhost:8080/doc.html显示404。原因SpringBoot 2.7.x默认禁用/doc.html路径需在application.yml显式开启。修复配置springfox: documentation: swagger: v2: path: /v2/api-docs # 并在 SwaggerConfig.java 中ensure ResourceHandler is registered5.4 毕设答辩专项避坑指南答辩演示卡顿提前关闭所有无关程序Chrome开无痕窗口禁用所有插件。用chrome://flags/#disable-gpu禁用GPU加速避免Canvas渲染卡顿。评委问“你怎么保证订单不超卖”别只答“用了Transactional”要说出具体措施1库存扣减SQL用UPDATE dish SET stock stock - #{number} WHERE id #{id} AND stock #{number}2执行后检查updateCount 0否则抛异常3整个下单流程加分布式锁虽本项目未实现但可说明“预留了Redis锁接口”。代码被质疑“太简单”主动展示common/GlobalExceptionHandler.java说明如何统一捕获CustomException并返回标准Result.error(库存不足)体现工程化思维。实操心得我让学生在答辩前用手机录一段3分钟全流程演示视频用户下单→骑手接单→完成配送→后台看板数据更新存在U盘里备用。万一现场网络故障直接播放视频评委照样给高分。这招百试百灵。6. 二次开发与功能拓展建议让毕设不止于“能跑”更要“能讲”这个项目的价值不仅在于它能跑通更在于它为你预留了清晰的扩展接口。我给学生的毕设加分项从来不是“加了个轮播图”而是“解决了某个真实业务痛点”。以下是三个经过验证的拓展方向附实现难度评级★☆☆☆☆为最易★★★★★为最难6.1 【★☆☆☆☆】增加“订单超时自动取消”功能推荐首选业务价值真实外卖平台用户下单后15分钟未支付订单自动关闭释放库存。技术实现- 后端在OrderServiceImpl中submit方法成功后用ThreadPoolTaskScheduler提交一个延迟任务javaAutowiredprivate ThreadPoolTaskScheduler taskScheduler;public void submit(Order order) {// …原有逻辑// 提交15分钟后执行的取消任务taskScheduler.schedule(() - {if (order.getStatus() 1) { // 仍是待支付order.setStatus(5); // 已取消order.setCancelReason(“超时未支付”);orderMapper.updateById(order);// 回滚库存…}}, new Date(System.currentTimeMillis() 15 * 60 * 1000));} - 前端在订单详情页用setInterval倒计时剩余时间≤0时提示“订单已关闭”。 **答辩亮点**能讲清“为什么用定时任务而不是数据库定时事件”因定时任务可动态取消数据库事件无法干预“如何避免重复执行”加is_cancelled字段双重校验。6.2 【★★★☆☆】集成微信支付沙箱环境业务价值让支付流程真实化不再是“点击支付→跳转成功页”的假流程。技术实现- 申请微信支付沙箱环境获取appid、mch_id、api_key- 后端新增PayController实现/user/pay/prepay接口调用微信统一下单API返回prepay_id- 前端调用WeixinJSBridge唤起微信支付需在微信内置浏览器中。关键避坑沙箱环境的notify_url必须是公网可访问地址本地开发可用ngrok映射签名算法必须严格按微信文档nonce_str要随机生成sign要按字典序拼接。6.3 【★★★★☆】实现“智能派单”算法进阶挑战业务价值替代人工“派单”按钮系统根据骑手位置、订单距离、当前任务数自动分配。技术实现- 后端新增DispatchService接入高德地图API的distance接口计算骑手到商家的距离- 综合权重距离40% 当前任务数30% 在线时长30%得分最低者胜出- 用Redis Sorted Set缓存骑手评分ZADD riders:score 85.2 rider_2ZRANGE riders:score 0 0取最优。答辩升华可对比“人工派单”与“智能派单”的平均配送时长数据用测试数据模拟证明算法价值。我个人在实际指导中发现学生最容易忽略的是数据验证。比如加微信支付很多同学只测了“支付成功”却忘了测“支付失败”“重复支付”“异步通知丢失”等异常场景。真正的工程能力体现在你能否写出覆盖所有分支的单元测试JUnit Mockito并在答辩PPT里展示测试覆盖率报告JaCoCo。这比炫酷的UI动画更能打动评委。最后分享一个小技巧把项目README.md写成一份“产品说明书”而不是“技术文档”。开头写“Reggie Lite是一款面向校园场景的轻量级外卖平台旨在解决食堂排队久、外卖选择少、配送不及时三大痛点”然后用流程图Mermaid语法但答辩时用PPT画展示“学生扫码点餐→食堂后厨接单→志愿者配送→扫码取餐”的闭环。技术细节放在附录。评委老师不是CTO他们想听的是“你解决了什么问题”而不是“你用了什么技术”。本文还有配套的精品资源点击获取简介直接运行的外卖平台完整工程后端基于SpringBoot开发提供RESTful接口涵盖商家入驻审核、菜品分类维护、购物车管理、用户下单、订单状态流转待支付/已接单/配送中/已完成、配送员任务分配等全流程功能前端采用Vue2构建双端页面——用户点餐页支持搜索、加购、地址选择与订单提交后台管理页集成数据看板、订单统计、员工与菜品管理模块MySQL建库脚本reggie.sql已包含表结构及初始化测试数据项目打包为可执行JAR配合Nginx部署前端静态资源本地启动无需额外中间件附带20余张真实界面截图覆盖登录、首页、菜品列表、购物车、订单详情、后台仪表盘等关键场景代码注释清晰、模块划分明确适合Java和Vue初学者上手调试也适配高校计算机专业毕业设计、课程设计或期末大作业需求支持快速二次开发与功能拓展。本文还有配套的精品资源点击获取
