这个标题我太熟了每年毕业季都能看到大量类似需求。Spring Boot加微信小程序做网上订餐几乎是食品类、计算机类毕设里最经典的组合之一。一个轻量的商家后台一个用户端小程序中间挂几个管理页面就能把前后端、数据库、移动端全部覆盖到。选这个题目的人多半不是冲着“创新”去的而是要一个能讲清楚、能演示、能跑通、能防住答辩追问的项目。今天这篇就把这类项目的完整骨架、核心实现、常见坑位和答辩准备一次性梳理清楚给正在做或准备做这个题目的同学一个直接能抄作业的参考。1. 项目整体设计与技术选型1.1 为什么毕设要选Spring Boot加小程序这套组合先聊选型。网上订餐这个业务本质是“用户浏览菜单、下单、商家接单出餐”的信息流转过程业务链路清楚、角色边界明确、状态转换有逻辑特别适合用来展示一个学生完整的工程能力。而Spring Boot加微信小程序这个组合恰恰是当前中小型Web应用和移动端应用最主流的搭配之一不是凭空拍脑袋选的。从答辩和展示的角度看Spring Boot的优势在于开箱即用、生态成熟。内置Tomcat不用额外配置外部容器打包成jar包就能跑这对毕设阶段要多次部署演示的场景非常友好。同时Spring Boot的注解式开发风格Controller、Service、Mapper分层清晰答辩时能很自然地讲出“表现层、业务层、数据访问层”三层架构的设计思路。小程序端就更不用说了微信生态自带海量用户小程序开发工具免费组件和API文档齐全UI渲染在手机上的效果比传统网页更有说服力。对比其他方案比如纯JSP加Servlet、SSHStrutsSpringHibernate、或者Vue加Spring Boot这几个方案要么太老旧无法体现现代开发思路要么前后端分离后光联调就够折腾一轮。而Spring Boot加小程序天然就是前后端分离通过HTTP接口通信这本身也是现在业界主流的开发模式。评委一看项目结构就知道你不是停留在教科书层面。1.2 系统角色与业务流程梳理这类网上订餐系统一般来说按照角色的不同功能范围会有差异。常见的角色划分是三层普通用户小程序端、商家管理员后台管理端、系统管理员可选项。如果毕设范围控制得当普通用户端加商家管理端这两个角色就足以覆盖完整业务闭环。普通用户在小程序端做到几个事情登录授权、浏览菜品分类、查看菜品详情、加入购物车、提交订单、查看历史订单、取消订单未接单状态下、管理收货地址。商家在后台做的事情菜品分类管理、菜品上下架维护、订单列表查看与状态更新接单、完成、销量统计等基础数据看板。如果还有余力加一个系统管理员角色去做商家账号管理也算是一种功能扩展。这个闭环的关键点在于订单状态机。我见过太多人把订单状态设计成一团乱麻前端几个按钮一通乱改后台一个update语句全部覆盖。正确做法是先把状态定义清楚。常见状态流转是待支付、已支付待接单或直接待接单、已接单、配送中可选、已完成、已取消。字段可以用Integer类型存储状态值并在代码里定义常量枚举不要散落着一堆魔鬼数字。1.3 项目目录结构与三层架构设计拿到毕设项目源码之后第一件事是理清目录结构。标准的Spring Boot项目主目录下包名一般是com.xxx.order之类内部再分包controller、service、mapper、entity或domain、config、common、dto、vo等。分包规则直接决定后续维护和答辩讲解的顺畅程度强烈建议从第一天就按规范分。Controller层只做参数接收、调用Service、结果封装这三件事业务逻辑不写在Controller里。Service层承载具体业务规则例如下单时库存扣减、订单状态校验。Mapper层就是数据访问对应MyBatis或MyBatis-Plus的接口。Entity对应数据库表结构DTO用于接收前端传入参数VO用于输出给前端的数据结构。这里有个常见误区很多人直接把Entity返回给前端结果密码字段泄露、多余字段一堆、字段名与前端不一致。正确做法是定义VO按需返回。在配置方面统一使用application.yml管理配置数据库连接、端口、日志级别都放进去。路径通配、拦截器配置、跨域配置放在config包独立管理。跨域这块一旦前后端分离部署几乎必踩后文会专门细说。2. 核心功能模块与数据库设计2.1 数据库表结构设计要点网上订餐系统的核心表我建议至少包含用户表user、菜品分类表category、菜品表dish、购物车表cart、订单表orders、订单明细表order_detail、地址表address。如果涉及商家账号再单独加一张管理员表admin。这些表之间的关系和字段设计直接决定后续开发的复杂度。用户表比较简单字段包括openid微信唯一标识、昵称、头像、手机号等。openid是关联微信登录的关键小程序端调用wx.login拿到code后端请求微信接口换openid这张表就是以openid为核心。菜品表需要关注的字段name、image、description、price用Decimal(10,2)、status1上架0下架、category_id、stock库存、create_time、update_time。注意价格永远不要用Float或Double浮点精度问题在涉及金额时会坑死人必须在数据库层就用DecimalJava侧对应BigDecimal。订单表是整张业务的核心字段包括order_no订单号、user_id、total_amount、status状态值、pay_time、delivery_address快照、remark。订单明细表则记录每道菜的购买数量、单价、小计通过order_id和订单表关联。为什么要单独拆订单明细因为一个订单对应多个菜品只有拆出来才能正确还原历史订单内容否则一个订单一行数据根本没法展示菜品列表。地址表字段包括user_id、consignee收货人、phone、province、city、district、detail、is_default。这里有个小细节下单时地址要复制进订单表做快照因为用户后续可能修改或删除地址但历史订单必须保留下单那一刻的地址信息不能动态关联。下面给出一份可以直接参考的建表SQL片段CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 用户ID, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 订单状态0待支付 1待接单 2已接单 3已完成 4已取消, address_snapshot varchar(255) DEFAULT NULL COMMENT 收货地址快照, remark varchar(255) DEFAULT NULL COMMENT 备注, pay_time datetime DEFAULT NULL COMMENT 支付时间, create_time datetime DEFAULT NULL COMMENT 下单时间, update_time datetime DEFAULT NULL COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;订单号唯一约束是必须的同时建议在后端用Redis或数据库序列生成订单号格式可以是时间戳加随机数避免并发下重复。2.2 数据库事务与并发控制订餐系统最容易出问题的环节在下单。一个用户下单后端要做的事情是查询菜品、校验库存、计算金额、生成主订单、生成订单明细、扣减库存这一连串操作必须是一个整体要么全成功要么全失败。所以下单接口必须加事务注解例如Transactional(rollbackFor Exception.class)。库存扣减也要小心。如果你的毕设达到了“多用户同时下单”的演示场景超卖问题就很难避免。方案有很多比如在dish表的stock字段上加乐观锁版本号或者用update语句的where条件直接判断stock 0。最简单的做法是在SQL层面扣减库存例如UPDATE dish SET stock stock - #{quantity} WHERE id #{dishId} AND stock #{quantity}受影响行数为0就说明库存不足直接抛出业务异常回滚。这种做法比先查询库存再更新要安全得多代码也简洁。毕设答辩时被问到“怎么解决并发问题”能答出这一层已经超出大部分人。2.3 通用设计规范返回结果统一封装前后端分离的项目接口返回数据必须有一个统一的封装格式否则小程序端处理起来痛苦不堪。建议定义一个通用返回类R或者Result包含code状态码、msg提示信息、data数据体三个字段。正常返回code为1或200业务异常code为0后端全局异常处理器统一捕获异常并返回R.error。Data public class RT implements Serializable { private Integer code; private String msg; private T data; public static T RT success(T data) { RT r new R(); r.setCode(1); r.setMsg(success); r.setData(data); return r; } public static T RT error(String msg) { RT r new R(); r.setCode(0); r.setMsg(msg); return r; } }同时配合全局异常处理器用RestControllerAdvice拦截所有异常统一转成上面的格式。这样Controller里就不用写一堆try-catch业务代码干净很多答辩也更容易讲出“统一异常处理”的设计亮点。3. 核心功能实现与代码逻辑3.1 小程序端微信登录与Token鉴权微信小程序登录是绝大多数微信生态项目的第一个环节。小程序端wx.login获取临时code发到后端后端拿code加AppId和AppSecret去微信接口换openid再以openid查询用户表如果不存在就自动注册一个新用户然后生成一个token返回给小程序端。小程序端后续每个请求都在header里带上token后端用拦截器校验。这里聊聊token的生成方案。毕设阶段没必要上太重的安全框架用JWT或UUID都可以。如果使用JWT要注意引入jjwt库的版本兼容问题使用UUID加Redis存储过期时间更简单可控。我个人更建议用UUID加Redis因为好解释、好排查代码量少答辩也好讲。拦截器配置要注意放行路径。登录接口必须放行菜品浏览等公开数据也可以放行涉及用户身份的操作加购物车、下单、订单查询必须拦截。对于小程序端如果token过期后端返回特定code比如401前端需要跳回登录页重新走登录流程。有一个小坑不得不提很多人在小程序request请求里拿不到后端返回的数据十有八九是dataType或者content-type类型没有配对。小程序post请求的header默认是application/json后端接口用RequestBody接收这两者必须对应否则后端拿不到参数。3.2 购物车与下单流程的实现细节购物车实现相对简单表结构上就是user_id、dish_id、quantity三个核心字段。加入购物车时先查当前用户、当前菜品是否已有记录有则数量加一没有则新增一条记录。这个逻辑需要注意并发场景下重复插入问题但毕设阶段锁好用户维度就可以了。下单流程是整个系统最核心的一段逻辑我这里给一段伪代码流程1. 接收下单请求包含收货地址ID、备注、购物车条目列表 2. 根据用户ID查询购物车数据 3. 遍历购物车查询菜品基本信息校验状态是否上架、库存是否充足 4. 计算订单总金额用数据库中的价格计算不信任前端传的价格 5. 生成订单号插入订单表状态待支付或待接单 6. 批量插入订单明细表 7. 扣减库存 8. 清除当前用户的购物车记录 9. 返回订单ID和订单号这套顺序是有讲究的。先查购物车、再校验库存、再计算金额每一步都基于数据库真实数据而不是直接信任前端传过来的金额这个习惯非常重要。我有一次看到有人直接从请求体里取totalAmount去保存结果前端改了一个数字整个订单金额就乱了这种低级错误答辩时容易被评委一针见血地指出。下单之后如果支付功能不做集成很多毕设没有真实商户号和支付权限可以直接把状态置为“待接单”或者在演示时提供一个“模拟支付”按钮前端调一个接口更新状态。这里要特别注意不做真实支付不代表“支付”功能不存在而是以模拟支付的方式存续。3.3 商家后台订单处理的实现思路商家管理后台的功能设计和实现经常被做这个题目的同学低估。很多人专心把小程序端打磨得很精致后台就敷衍了事结果答辩演示时商家端漏洞百出。实际上商家后台才是体现系统“管理型”特质的关键模块。商家后台建议用浏览器访问的Web页面或者用另一个简单管理端页面技术栈可以继续用Spring Boot配模板引擎如Thymeleaf也可以独立一个纯前端页面。功能上至少要有分类管理、菜品管理、订单管理三个模块。订单管理是核心。商家操作包括查看新订单、接单状态从待接单变成已接单、完成订单状态变成已完成。这里注意权限控制商家只能操作自己店铺的订单如果系统设计为多商家单商家场景就无所谓了。接单时校验当前订单状态必须是待接单防止重复操作。如果后台页面用Thymeleaf要注意模板引擎的版本和Spring Boot版本兼容问题。Spring Boot 3.x对Thymeleaf的要求和2.x有差异很多老教程已经不适用了这个要特别留意。4. 小程序端开发与前后端联调4.1 小程序端页面结构与请求封装小程序端页面关系不复杂核心页面包括首页展示分类和菜品、购物车页、提交订单页、订单列表页、订单详情页、个人中心页。如果使用原生小程序开发每个页面由wxml、wxss、js、json四个文件构成页面之间的跳转通过路由实现。项目的app.js里要维护全局数据例如用户登录态、购物车数量角标。这里有个移动端常见的坑购物车数量在多个页面间同步问题。如果用户在菜品详情页加购返回首页时角标要更新这种跨页面状态同步用全局变量或事件总线可以解决也可以用页面onshow时重新拉取购物车总数的方式简单可靠。请求封装建议在utils目录下封装一个request方法统一处理baseUrl、header里的token、响应拦截例如code为401时自动跳登录页等。所有业务页面都调用这个封装好的方法不要写一堆重复的wx.request。baseUrl的配置更要注意开发环境用本机IP加端口真机调试时localhost是打不开的必须换成电脑的局域网IP上线时再改成线上域名。4.2 前后端接口联调与跨域问题排查联调阶段是比较折磨人的。常见的接口联调问题可以整理成以下排查清单现象可能原因解决方案小程序请求报错“url not in domain list”后台没有配置合法域名或使用了IP地址开发工具中勾选“不校验合法域名”请求报404后端接口路径错误或Controller没有映射检查RequestMapping路径避免重复前缀请求报500后端代码异常看后端日志多数是SQL或空指针问题请求正常返回但前端data是undefined返回结构不是预期格式检查R封装格式确认数据在data字段中POST请求后端接收不到参数contentType不匹配统一JSON格式后端RequestBody接收真机预览请求不通手机无法访问电脑IP同一局域网防火墙放行端口用局域网IP访问跨域问题主要在后台管理页面调用后端接口时出现。Spring Boot解决跨域最简单的方式是写一个CorsConfig配置类注册CorsFilter并允许所有来源和方法。小程序端不存在浏览器跨域问题但后台Web管理端有。4.3 支付模块的取舍与演示替代方案支付这个点我单独拿出来说是因为这是毕设项目最容易卡住的地方。真实微信支付需要企业主体、商户号、微信认证、支付证书等一系列前置条件个人开发者在毕设阶段通常很难全部搞定。而且小程序后台需要配置支付域名和商户号关联如果资质不全根本无法完成真实支付流程。毕设答辩时正确策略是在系统设计里预留支付模块但是在演示环境用“模拟支付”来代替。做法是前端在确认支付时弹窗提示“模拟支付成功”然后调用后端的支付回调模拟接口将订单状态从待支付更新为已支付。后端预留了真正对接微信支付V3的接口结构但注释说明需要商户号等真实配置。如果有人准备做真实支付对接那就要准备好企业资质、商户号等材料同时小程序端需要调用wx.requestPayment后端对接下单接口和回调接口。这里涉及证书、签名、回调验签等一堆环节。考虑到大部分人的现实条件我更建议用模拟支付答辩时主动说明“因为缺少商户资质支付模块以模拟支付实现但已预留真实接口”这个说法大部分评委都能接受。5. 部署、文档编写与毕设答辩避坑指南5.1 项目部署与演示环境准备毕设演示前部署环节一定要提前踩完坑。最常见的情况是代码在IDEA里跑得好好的一部署到答辩环境就各种问题。建议提前把环境固定在Linux服务器上并且多演练两遍。部署时要注意几点服务器上安装JDK版本与本地保持一致、MySQL注意字符集编码utf8mb4、Redis如果有用到然后打包上传Spring Boot项目的jar包用nohup方式后台启动。小程序端如果要做真机演示需要将后端部署到有公网域名的服务器上在小程序后台配置合法域名。如果没有公网环境退而求其次用开发者工具的“不校验合法域名”选项但演示时要确保工具和电脑端环境都提前准备好。启动项目后有一个特别容易被忽略的坑MySQL时区问题。如果数据库中时间少8小时多半是连接串上没有配置serverTimezone或者服务器默认时区不是中国标准时间。解决办法是在连接串中加参数serverTimezoneAsia/Shanghai或者在jdbc url中加serverTimezoneGMT%2B8。5.2 毕设文档结构与答辩讲稿准备毕设论文的框架一般包含摘要、绪论研究背景、意义、国内外现状、需求分析、系统设计、数据库设计、系统实现、系统测试、总结与展望。这个过程很多人都卡在需求分析和系统设计上其实有一个讨巧的方法按照用例图、功能架构图、流程图、ER图这个顺序来写先把图构建出来再根据图去写文字。写论文时要注意图文并茂界面截图要有。菜品列表页、购物车页、订单详情页、后台订单管理页这四张截图基本是必放的。每张截图旁都要配功能描述和实现要点例如“菜品列表页展示菜品分类和菜品卡片点击卡片跳转详情页”。答辩讲稿准备核心是讲清楚三句话我的系统是什么解决了什么问题我的系统有哪些功能技术怎么实现的我做这个系统花了哪些功夫。演示时操作顺序建议是先用小程序端走一遍完整的点餐流程浏览菜品、加购物车、下单、查看订单再切到后台管理端接单、完成订单形成一个完整的业务闭环最后展示数据库数据的变化。答辩时评委大概率问的几个问题提前准备答案为什么选Spring BootMyBatis和MyBatis-Plus的区别订单状态是怎么管理的如果用户并发下单库存怎么保证不超卖微信登录的流程是什么项目部署在哪里数据库怎么设计的这些问题分别对应技术选型、框架理解、业务逻辑、并发处理、Api对接和系统部署都在前面的章节里覆盖到了认真看完这篇就能答上大半。5.3 源码整理与代码讲解注意事项交付的源码包一定要保证拿到的人能“即开即跑”。我见过太多人把target目录、本地日志、个人配置文件一起打进压缩包或者数据库脚本导出格式有问题导入报错。整理源码时注意清理所有无关注释和测试代码数据库脚本要用Navicat或mysqldump完整导出包含表结构和测试数据的SQL文件配置文件中数据库密码移除真实密码或用统一占位README.md文件写清楚项目简介、技术栈、启动步骤、默认账号和目录结构。代码讲解如果拍成视频建议按模块讲先讲项目结构、再讲数据库表设计、然后讲登录模块、菜品模块、购物车模块、订单模块最后讲部署演示。这样听众能按顺序建立起整体认知。录制时画面分辨率要清晰代码字体调大一点讲解语言提前写个简单提纲避免讲的时候卡壳或者跳来跳去。我想再分享一个做毕设源码分享项目的老经验代码里每个类的头部、每个关键方法上都写清楚注释这不只是为了应付检查更大的好处是一周之后你再回头看自己的代码能三分钟定位到要改的地方。我接手过太多反馈说“源码跑不起来”的求助几乎有八成问题都出在环境差异和数据库脚本没导入正确上而不是代码本身的问题提前把注释和文档做细致能减少大量无意义的时间消耗。整理完这套项目你会对Spring Boot和小程序开发的完整流程有一个非常务实的理解。从数据建模、接口设计、异常处理到小程序端的状态同步和部署上线每个环节都有对应的真实工程解决方案。把这篇里的要点逐条落地你在毕业答辩和日后的面试里都能讲出真正有价值的项目经验。
这个标题我太熟了每年毕业季都能看到大量类似需求。Spring Boot加微信小程序做网上订餐几乎是食品类、计算机类毕设里最经典的组合之一。一个轻量的商家后台一个用户端小程序中间挂几个管理页面就能把前后端、数据库、移动端全部覆盖到。选这个题目的人多半不是冲着“创新”去的而是要一个能讲清楚、能演示、能跑通、能防住答辩追问的项目。今天这篇就把这类项目的完整骨架、核心实现、常见坑位和答辩准备一次性梳理清楚给正在做或准备做这个题目的同学一个直接能抄作业的参考。1. 项目整体设计与技术选型1.1 为什么毕设要选Spring Boot加小程序这套组合先聊选型。网上订餐这个业务本质是“用户浏览菜单、下单、商家接单出餐”的信息流转过程业务链路清楚、角色边界明确、状态转换有逻辑特别适合用来展示一个学生完整的工程能力。而Spring Boot加微信小程序这个组合恰恰是当前中小型Web应用和移动端应用最主流的搭配之一不是凭空拍脑袋选的。从答辩和展示的角度看Spring Boot的优势在于开箱即用、生态成熟。内置Tomcat不用额外配置外部容器打包成jar包就能跑这对毕设阶段要多次部署演示的场景非常友好。同时Spring Boot的注解式开发风格Controller、Service、Mapper分层清晰答辩时能很自然地讲出“表现层、业务层、数据访问层”三层架构的设计思路。小程序端就更不用说了微信生态自带海量用户小程序开发工具免费组件和API文档齐全UI渲染在手机上的效果比传统网页更有说服力。对比其他方案比如纯JSP加Servlet、SSHStrutsSpringHibernate、或者Vue加Spring Boot这几个方案要么太老旧无法体现现代开发思路要么前后端分离后光联调就够折腾一轮。而Spring Boot加小程序天然就是前后端分离通过HTTP接口通信这本身也是现在业界主流的开发模式。评委一看项目结构就知道你不是停留在教科书层面。1.2 系统角色与业务流程梳理这类网上订餐系统一般来说按照角色的不同功能范围会有差异。常见的角色划分是三层普通用户小程序端、商家管理员后台管理端、系统管理员可选项。如果毕设范围控制得当普通用户端加商家管理端这两个角色就足以覆盖完整业务闭环。普通用户在小程序端做到几个事情登录授权、浏览菜品分类、查看菜品详情、加入购物车、提交订单、查看历史订单、取消订单未接单状态下、管理收货地址。商家在后台做的事情菜品分类管理、菜品上下架维护、订单列表查看与状态更新接单、完成、销量统计等基础数据看板。如果还有余力加一个系统管理员角色去做商家账号管理也算是一种功能扩展。这个闭环的关键点在于订单状态机。我见过太多人把订单状态设计成一团乱麻前端几个按钮一通乱改后台一个update语句全部覆盖。正确做法是先把状态定义清楚。常见状态流转是待支付、已支付待接单或直接待接单、已接单、配送中可选、已完成、已取消。字段可以用Integer类型存储状态值并在代码里定义常量枚举不要散落着一堆魔鬼数字。1.3 项目目录结构与三层架构设计拿到毕设项目源码之后第一件事是理清目录结构。标准的Spring Boot项目主目录下包名一般是com.xxx.order之类内部再分包controller、service、mapper、entity或domain、config、common、dto、vo等。分包规则直接决定后续维护和答辩讲解的顺畅程度强烈建议从第一天就按规范分。Controller层只做参数接收、调用Service、结果封装这三件事业务逻辑不写在Controller里。Service层承载具体业务规则例如下单时库存扣减、订单状态校验。Mapper层就是数据访问对应MyBatis或MyBatis-Plus的接口。Entity对应数据库表结构DTO用于接收前端传入参数VO用于输出给前端的数据结构。这里有个常见误区很多人直接把Entity返回给前端结果密码字段泄露、多余字段一堆、字段名与前端不一致。正确做法是定义VO按需返回。在配置方面统一使用application.yml管理配置数据库连接、端口、日志级别都放进去。路径通配、拦截器配置、跨域配置放在config包独立管理。跨域这块一旦前后端分离部署几乎必踩后文会专门细说。2. 核心功能模块与数据库设计2.1 数据库表结构设计要点网上订餐系统的核心表我建议至少包含用户表user、菜品分类表category、菜品表dish、购物车表cart、订单表orders、订单明细表order_detail、地址表address。如果涉及商家账号再单独加一张管理员表admin。这些表之间的关系和字段设计直接决定后续开发的复杂度。用户表比较简单字段包括openid微信唯一标识、昵称、头像、手机号等。openid是关联微信登录的关键小程序端调用wx.login拿到code后端请求微信接口换openid这张表就是以openid为核心。菜品表需要关注的字段name、image、description、price用Decimal(10,2)、status1上架0下架、category_id、stock库存、create_time、update_time。注意价格永远不要用Float或Double浮点精度问题在涉及金额时会坑死人必须在数据库层就用DecimalJava侧对应BigDecimal。订单表是整张业务的核心字段包括order_no订单号、user_id、total_amount、status状态值、pay_time、delivery_address快照、remark。订单明细表则记录每道菜的购买数量、单价、小计通过order_id和订单表关联。为什么要单独拆订单明细因为一个订单对应多个菜品只有拆出来才能正确还原历史订单内容否则一个订单一行数据根本没法展示菜品列表。地址表字段包括user_id、consignee收货人、phone、province、city、district、detail、is_default。这里有个小细节下单时地址要复制进订单表做快照因为用户后续可能修改或删除地址但历史订单必须保留下单那一刻的地址信息不能动态关联。下面给出一份可以直接参考的建表SQL片段CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 用户ID, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 订单状态0待支付 1待接单 2已接单 3已完成 4已取消, address_snapshot varchar(255) DEFAULT NULL COMMENT 收货地址快照, remark varchar(255) DEFAULT NULL COMMENT 备注, pay_time datetime DEFAULT NULL COMMENT 支付时间, create_time datetime DEFAULT NULL COMMENT 下单时间, update_time datetime DEFAULT NULL COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;订单号唯一约束是必须的同时建议在后端用Redis或数据库序列生成订单号格式可以是时间戳加随机数避免并发下重复。2.2 数据库事务与并发控制订餐系统最容易出问题的环节在下单。一个用户下单后端要做的事情是查询菜品、校验库存、计算金额、生成主订单、生成订单明细、扣减库存这一连串操作必须是一个整体要么全成功要么全失败。所以下单接口必须加事务注解例如Transactional(rollbackFor Exception.class)。库存扣减也要小心。如果你的毕设达到了“多用户同时下单”的演示场景超卖问题就很难避免。方案有很多比如在dish表的stock字段上加乐观锁版本号或者用update语句的where条件直接判断stock 0。最简单的做法是在SQL层面扣减库存例如UPDATE dish SET stock stock - #{quantity} WHERE id #{dishId} AND stock #{quantity}受影响行数为0就说明库存不足直接抛出业务异常回滚。这种做法比先查询库存再更新要安全得多代码也简洁。毕设答辩时被问到“怎么解决并发问题”能答出这一层已经超出大部分人。2.3 通用设计规范返回结果统一封装前后端分离的项目接口返回数据必须有一个统一的封装格式否则小程序端处理起来痛苦不堪。建议定义一个通用返回类R或者Result包含code状态码、msg提示信息、data数据体三个字段。正常返回code为1或200业务异常code为0后端全局异常处理器统一捕获异常并返回R.error。Data public class RT implements Serializable { private Integer code; private String msg; private T data; public static T RT success(T data) { RT r new R(); r.setCode(1); r.setMsg(success); r.setData(data); return r; } public static T RT error(String msg) { RT r new R(); r.setCode(0); r.setMsg(msg); return r; } }同时配合全局异常处理器用RestControllerAdvice拦截所有异常统一转成上面的格式。这样Controller里就不用写一堆try-catch业务代码干净很多答辩也更容易讲出“统一异常处理”的设计亮点。3. 核心功能实现与代码逻辑3.1 小程序端微信登录与Token鉴权微信小程序登录是绝大多数微信生态项目的第一个环节。小程序端wx.login获取临时code发到后端后端拿code加AppId和AppSecret去微信接口换openid再以openid查询用户表如果不存在就自动注册一个新用户然后生成一个token返回给小程序端。小程序端后续每个请求都在header里带上token后端用拦截器校验。这里聊聊token的生成方案。毕设阶段没必要上太重的安全框架用JWT或UUID都可以。如果使用JWT要注意引入jjwt库的版本兼容问题使用UUID加Redis存储过期时间更简单可控。我个人更建议用UUID加Redis因为好解释、好排查代码量少答辩也好讲。拦截器配置要注意放行路径。登录接口必须放行菜品浏览等公开数据也可以放行涉及用户身份的操作加购物车、下单、订单查询必须拦截。对于小程序端如果token过期后端返回特定code比如401前端需要跳回登录页重新走登录流程。有一个小坑不得不提很多人在小程序request请求里拿不到后端返回的数据十有八九是dataType或者content-type类型没有配对。小程序post请求的header默认是application/json后端接口用RequestBody接收这两者必须对应否则后端拿不到参数。3.2 购物车与下单流程的实现细节购物车实现相对简单表结构上就是user_id、dish_id、quantity三个核心字段。加入购物车时先查当前用户、当前菜品是否已有记录有则数量加一没有则新增一条记录。这个逻辑需要注意并发场景下重复插入问题但毕设阶段锁好用户维度就可以了。下单流程是整个系统最核心的一段逻辑我这里给一段伪代码流程1. 接收下单请求包含收货地址ID、备注、购物车条目列表 2. 根据用户ID查询购物车数据 3. 遍历购物车查询菜品基本信息校验状态是否上架、库存是否充足 4. 计算订单总金额用数据库中的价格计算不信任前端传的价格 5. 生成订单号插入订单表状态待支付或待接单 6. 批量插入订单明细表 7. 扣减库存 8. 清除当前用户的购物车记录 9. 返回订单ID和订单号这套顺序是有讲究的。先查购物车、再校验库存、再计算金额每一步都基于数据库真实数据而不是直接信任前端传过来的金额这个习惯非常重要。我有一次看到有人直接从请求体里取totalAmount去保存结果前端改了一个数字整个订单金额就乱了这种低级错误答辩时容易被评委一针见血地指出。下单之后如果支付功能不做集成很多毕设没有真实商户号和支付权限可以直接把状态置为“待接单”或者在演示时提供一个“模拟支付”按钮前端调一个接口更新状态。这里要特别注意不做真实支付不代表“支付”功能不存在而是以模拟支付的方式存续。3.3 商家后台订单处理的实现思路商家管理后台的功能设计和实现经常被做这个题目的同学低估。很多人专心把小程序端打磨得很精致后台就敷衍了事结果答辩演示时商家端漏洞百出。实际上商家后台才是体现系统“管理型”特质的关键模块。商家后台建议用浏览器访问的Web页面或者用另一个简单管理端页面技术栈可以继续用Spring Boot配模板引擎如Thymeleaf也可以独立一个纯前端页面。功能上至少要有分类管理、菜品管理、订单管理三个模块。订单管理是核心。商家操作包括查看新订单、接单状态从待接单变成已接单、完成订单状态变成已完成。这里注意权限控制商家只能操作自己店铺的订单如果系统设计为多商家单商家场景就无所谓了。接单时校验当前订单状态必须是待接单防止重复操作。如果后台页面用Thymeleaf要注意模板引擎的版本和Spring Boot版本兼容问题。Spring Boot 3.x对Thymeleaf的要求和2.x有差异很多老教程已经不适用了这个要特别留意。4. 小程序端开发与前后端联调4.1 小程序端页面结构与请求封装小程序端页面关系不复杂核心页面包括首页展示分类和菜品、购物车页、提交订单页、订单列表页、订单详情页、个人中心页。如果使用原生小程序开发每个页面由wxml、wxss、js、json四个文件构成页面之间的跳转通过路由实现。项目的app.js里要维护全局数据例如用户登录态、购物车数量角标。这里有个移动端常见的坑购物车数量在多个页面间同步问题。如果用户在菜品详情页加购返回首页时角标要更新这种跨页面状态同步用全局变量或事件总线可以解决也可以用页面onshow时重新拉取购物车总数的方式简单可靠。请求封装建议在utils目录下封装一个request方法统一处理baseUrl、header里的token、响应拦截例如code为401时自动跳登录页等。所有业务页面都调用这个封装好的方法不要写一堆重复的wx.request。baseUrl的配置更要注意开发环境用本机IP加端口真机调试时localhost是打不开的必须换成电脑的局域网IP上线时再改成线上域名。4.2 前后端接口联调与跨域问题排查联调阶段是比较折磨人的。常见的接口联调问题可以整理成以下排查清单现象可能原因解决方案小程序请求报错“url not in domain list”后台没有配置合法域名或使用了IP地址开发工具中勾选“不校验合法域名”请求报404后端接口路径错误或Controller没有映射检查RequestMapping路径避免重复前缀请求报500后端代码异常看后端日志多数是SQL或空指针问题请求正常返回但前端data是undefined返回结构不是预期格式检查R封装格式确认数据在data字段中POST请求后端接收不到参数contentType不匹配统一JSON格式后端RequestBody接收真机预览请求不通手机无法访问电脑IP同一局域网防火墙放行端口用局域网IP访问跨域问题主要在后台管理页面调用后端接口时出现。Spring Boot解决跨域最简单的方式是写一个CorsConfig配置类注册CorsFilter并允许所有来源和方法。小程序端不存在浏览器跨域问题但后台Web管理端有。4.3 支付模块的取舍与演示替代方案支付这个点我单独拿出来说是因为这是毕设项目最容易卡住的地方。真实微信支付需要企业主体、商户号、微信认证、支付证书等一系列前置条件个人开发者在毕设阶段通常很难全部搞定。而且小程序后台需要配置支付域名和商户号关联如果资质不全根本无法完成真实支付流程。毕设答辩时正确策略是在系统设计里预留支付模块但是在演示环境用“模拟支付”来代替。做法是前端在确认支付时弹窗提示“模拟支付成功”然后调用后端的支付回调模拟接口将订单状态从待支付更新为已支付。后端预留了真正对接微信支付V3的接口结构但注释说明需要商户号等真实配置。如果有人准备做真实支付对接那就要准备好企业资质、商户号等材料同时小程序端需要调用wx.requestPayment后端对接下单接口和回调接口。这里涉及证书、签名、回调验签等一堆环节。考虑到大部分人的现实条件我更建议用模拟支付答辩时主动说明“因为缺少商户资质支付模块以模拟支付实现但已预留真实接口”这个说法大部分评委都能接受。5. 部署、文档编写与毕设答辩避坑指南5.1 项目部署与演示环境准备毕设演示前部署环节一定要提前踩完坑。最常见的情况是代码在IDEA里跑得好好的一部署到答辩环境就各种问题。建议提前把环境固定在Linux服务器上并且多演练两遍。部署时要注意几点服务器上安装JDK版本与本地保持一致、MySQL注意字符集编码utf8mb4、Redis如果有用到然后打包上传Spring Boot项目的jar包用nohup方式后台启动。小程序端如果要做真机演示需要将后端部署到有公网域名的服务器上在小程序后台配置合法域名。如果没有公网环境退而求其次用开发者工具的“不校验合法域名”选项但演示时要确保工具和电脑端环境都提前准备好。启动项目后有一个特别容易被忽略的坑MySQL时区问题。如果数据库中时间少8小时多半是连接串上没有配置serverTimezone或者服务器默认时区不是中国标准时间。解决办法是在连接串中加参数serverTimezoneAsia/Shanghai或者在jdbc url中加serverTimezoneGMT%2B8。5.2 毕设文档结构与答辩讲稿准备毕设论文的框架一般包含摘要、绪论研究背景、意义、国内外现状、需求分析、系统设计、数据库设计、系统实现、系统测试、总结与展望。这个过程很多人都卡在需求分析和系统设计上其实有一个讨巧的方法按照用例图、功能架构图、流程图、ER图这个顺序来写先把图构建出来再根据图去写文字。写论文时要注意图文并茂界面截图要有。菜品列表页、购物车页、订单详情页、后台订单管理页这四张截图基本是必放的。每张截图旁都要配功能描述和实现要点例如“菜品列表页展示菜品分类和菜品卡片点击卡片跳转详情页”。答辩讲稿准备核心是讲清楚三句话我的系统是什么解决了什么问题我的系统有哪些功能技术怎么实现的我做这个系统花了哪些功夫。演示时操作顺序建议是先用小程序端走一遍完整的点餐流程浏览菜品、加购物车、下单、查看订单再切到后台管理端接单、完成订单形成一个完整的业务闭环最后展示数据库数据的变化。答辩时评委大概率问的几个问题提前准备答案为什么选Spring BootMyBatis和MyBatis-Plus的区别订单状态是怎么管理的如果用户并发下单库存怎么保证不超卖微信登录的流程是什么项目部署在哪里数据库怎么设计的这些问题分别对应技术选型、框架理解、业务逻辑、并发处理、Api对接和系统部署都在前面的章节里覆盖到了认真看完这篇就能答上大半。5.3 源码整理与代码讲解注意事项交付的源码包一定要保证拿到的人能“即开即跑”。我见过太多人把target目录、本地日志、个人配置文件一起打进压缩包或者数据库脚本导出格式有问题导入报错。整理源码时注意清理所有无关注释和测试代码数据库脚本要用Navicat或mysqldump完整导出包含表结构和测试数据的SQL文件配置文件中数据库密码移除真实密码或用统一占位README.md文件写清楚项目简介、技术栈、启动步骤、默认账号和目录结构。代码讲解如果拍成视频建议按模块讲先讲项目结构、再讲数据库表设计、然后讲登录模块、菜品模块、购物车模块、订单模块最后讲部署演示。这样听众能按顺序建立起整体认知。录制时画面分辨率要清晰代码字体调大一点讲解语言提前写个简单提纲避免讲的时候卡壳或者跳来跳去。我想再分享一个做毕设源码分享项目的老经验代码里每个类的头部、每个关键方法上都写清楚注释这不只是为了应付检查更大的好处是一周之后你再回头看自己的代码能三分钟定位到要改的地方。我接手过太多反馈说“源码跑不起来”的求助几乎有八成问题都出在环境差异和数据库脚本没导入正确上而不是代码本身的问题提前把注释和文档做细致能减少大量无意义的时间消耗。整理完这套项目你会对Spring Boot和小程序开发的完整流程有一个非常务实的理解。从数据建模、接口设计、异常处理到小程序端的状态同步和部署上线每个环节都有对应的真实工程解决方案。把这篇里的要点逐条落地你在毕业答辩和日后的面试里都能讲出真正有价值的项目经验。
