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、SSH（Struts+Spring+Hibernate）、或者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)）、status（1上架0下架）、category_id、stock（库存）、create_time、update_time。注意价格永远不要用Float或Double，浮点精度问题在涉及金额时会坑死人，必须在数据库层就用Decimal，Java侧对应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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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 R<T> implements Serializable { private Integer code; private String msg; private T data; public static <T> R<T> success(T data) { R<T> r = new R<>(); r.setCode(1); r.setMsg("success"); r.setData(data); return r; } public static <T> R<T> error(String msg) { R<T> 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 前后端接口联调与跨域问题排查

联调阶段是比较折磨人的。常见的接口联调问题可以整理成以下排查清单：

跨域问题主要在后台管理页面调用后端接口时出现。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，或者服务器默认时区不是中国标准时间。解决办法是在连接串中加参数serverTimezone=Asia/Shanghai，或者在jdbc url中加&serverTimezone=GMT%2B8。

5.2 毕设文档结构与答辩讲稿准备

毕设论文的框架，一般包含摘要、绪论（研究背景、意义、国内外现状）、需求分析、系统设计、数据库设计、系统实现、系统测试、总结与展望。这个过程很多人都卡在需求分析和系统设计上，其实有一个讨巧的方法：按照用例图、功能架构图、流程图、ER图这个顺序来写，先把图构建出来，再根据图去写文字。

写论文时要注意图文并茂，界面截图要有。菜品列表页、购物车页、订单详情页、后台订单管理页，这四张截图基本是必放的。每张截图旁都要配功能描述和实现要点，例如“菜品列表页展示菜品分类和菜品卡片，点击卡片跳转详情页”。

答辩讲稿准备，核心是讲清楚三句话：我的系统是什么，解决了什么问题；我的系统有哪些功能，技术怎么实现的；我做这个系统花了哪些功夫。演示时操作顺序建议是：先用小程序端走一遍完整的点餐流程（浏览菜品、加购物车、下单、查看订单），再切到后台管理端接单、完成订单，形成一个完整的业务闭环，最后展示数据库数据的变化。

答辩时评委大概率问的几个问题，提前准备答案：为什么选Spring Boot？MyBatis和MyBatis-Plus的区别？订单状态是怎么管理的？如果用户并发下单，库存怎么保证不超卖？微信登录的流程是什么？项目部署在哪里，数据库怎么设计的？这些问题分别对应技术选型、框架理解、业务逻辑、并发处理、Api对接和系统部署，都在前面的章节里覆盖到了，认真看完这篇就能答上大半。

5.3 源码整理与代码讲解注意事项

交付的源码包，一定要保证拿到的人能“即开即跑”。我见过太多人把target目录、本地日志、个人配置文件一起打进压缩包，或者数据库脚本导出格式有问题，导入报错。整理源码时注意清理所有无关注释和测试代码；数据库脚本要用Navicat或mysqldump完整导出包含表结构和测试数据的SQL文件；配置文件中数据库密码移除真实密码或用统一占位；README.md文件写清楚项目简介、技术栈、启动步骤、默认账号和目录结构。

代码讲解如果拍成视频，建议按模块讲：先讲项目结构、再讲数据库表设计、然后讲登录模块、菜品模块、购物车模块、订单模块，最后讲部署演示。这样听众能按顺序建立起整体认知。录制时画面分辨率要清晰，代码字体调大一点，讲解语言提前写个简单提纲，避免讲的时候卡壳或者跳来跳去。

我想再分享一个做毕设源码分享项目的老经验：代码里每个类的头部、每个关键方法上都写清楚注释，这不只是为了应付检查，更大的好处是一周之后你再回头看自己的代码，能三分钟定位到要改的地方。我接手过太多反馈说“源码跑不起来”的求助，几乎有八成问题都出在环境差异和数据库脚本没导入正确上，而不是代码本身的问题，提前把注释和文档做细致，能减少大量无意义的时间消耗。

整理完这套项目，你会对Spring Boot和小程序开发的完整流程有一个非常务实的理解。从数据建模、接口设计、异常处理，到小程序端的状态同步和部署上线，每个环节都有对应的真实工程解决方案。把这篇里的要点逐条落地，你在毕业答辩和日后的面试里都能讲出真正有价值的项目经验。