简介一份围绕基于微信小程序的外卖点单系统展开的毕业论文文档面向计算机专业毕业生、毕设选题学生以及想了解Spring Boot后端与微信小程序前端联动开发的入门开发者。文档从外卖行业现状切入梳理了用户端浏览菜品、在线下单、订单状态确认与管理端菜品类型管理、菜品信息维护、订单处理等核心功能并对系统设计、数据库架构、服务器接口开发以及功能测试、性能测试、兼容性测试等环节作了详细说明能够帮助读者快速掌握此类毕设项目的整体流程与论文写法。资源包内只有一个docx文件大小约2.05MB包含摘要、关键词、目录、完整正文及参考文献可直接用于论文框架参考或学习摘录。目前已有207人学习适合需要完成外卖点单小程序设计与实现、或正在撰写相关课题论文的学生使用。1. 一篇 docx 论文真不是一套能直接抄的源码拿到「springboot基于微信小程序的外卖点单系统论文.docx」这个标题不少人的第一反应是去找源码压缩包。但这份交付物的核心其实是一个 Word 文档也就是说你手里握着的是一份「设计说得通」的需求与方案说明书而不是「能直接运行」的工程代码。这篇笔记要解决的就是这个落差手里只有论文、没有完整工程时怎么把 Spring Boot 后端和微信小程序端的前后端分离外卖系统一步步落地让实现和论文里的功能描述对得上号。我会按一个可复现的顺序来走先讲怎么从论文目录反推数据表再讲订单状态机这类后端硬骨头接着处理小程序端的点单和订阅消息最后是真机联调里的几个高频翻车点。整个过程不依赖任何你没见过的黑科技全是 Spring Boot 2.7 MyBatis-Plus MySQL 8.0 微信开发者工具这套常规组合。适合正在做外卖点单类毕设或练手项目、但手里只有论文草稿的开发者也适合想快速搭一套点单 Demo 再去补充业务细节的熟手。2. 先拆论文再写库从 docx 反推外卖系统的表结构2.1 从论文目录反推功能树一张接口清单就够了拿到论文后我习惯先跳过「绪论」和「技术介绍」这两章直接看系统分析、数据库设计和界面截图。原因很简单毕设论文的绪论部分大多是背景描述对写代码没有直接输入而功能需求那一章通常会把用户角色、功能模块和用例图画清楚。我拿到一篇典型的外卖点单系统论文时会先把目录里涉及功能的章节扫一遍提取出下面这类关键词用户注册登录、浏览菜品、购物车、下单结算、订单管理、商家接单、配送状态、历史订单。这些关键词会直接映射成一组 RESTful 接口清单比如 POST /api/order 是用户下单PUT /api/order/status 是商家更新订单状态。这一步看起来简单但很容易被人跳过。不少同学直接照着别人分享的源码建库结果发现论文里写的「菜品规格」功能在源码里根本不存在最后答辩时被问得下不来台。正确做法是把论文里提到但源码里没有的功能列成一张差异表哪怕先不做也要在数据库设计上留出扩展空间。我一般会在纸上画一张 5 列的表模块名、论文里的功能描述、对应接口路径、对应表、当前实现状态写完之后再动数据库。2.2 订单才是核心三张表的字段设计决定后面好不好写外卖点单系统里最容易设计错的是订单相关表。很多初学的人会把订单、订单明细、商品这三张表混在一起或者把商品价格和订单快照价格当成同一个字段。实际上商品价格会变但用户下单那一刻的价格必须被永久记录在订单明细里否则后续对账和订单详情页根本没法做。我常用的是三张核心表商品表 product、订单表 orders、订单明细表 order_item。外加购物车表 cart——虽然小程序端购物车也可以用本地缓存实现但考虑到论文里通常有「我的购物车」的数据库设计章节我选择把它落成表这样论文里的 E-R 图能对上。这三张表的字段设计有几个关键决策。第一orders 表里必须有 order_no 业务单号用时间戳加随机数生成不能直接用自增主键给用户看否则用户会拿单号去猜订单量。第二order_item 表里要冗余 product_name 和 product_price这两个字段在订单生成时从商品表复制过来后续商品改名、改价都不影响历史订单展示。第三orders 表里要有 status 字段我会用 tinyint 存状态值而不是直接存字符串这样状态机好写也方便前端映射。2.3 建表和实体的落地从 E-R 图到 SQL 不是照抄数据库设计章节的 E-R 图通常只画实体和关系不会告诉你每个字段的类型和长度。这里需要自己补齐约定id 用 bigint金额用 decimal(10,2)时间用 datetime状态用 tinyint。我自己整理出一套 SQL每次做这类系统都从这套模板改起。CREATE TABLE product ( id bigint NOT NULL AUTO_INCREMENT, name varchar(64) NOT NULL COMMENT 菜品名称, price decimal(10,2) NOT NULL COMMENT 售价, image varchar(255) DEFAULT NULL COMMENT 图片URL, category varchar(32) NOT NULL COMMENT 分类, stock int NOT NULL DEFAULT 0 COMMENT 库存, status tinyint NOT NULL DEFAULT 1 COMMENT 1上架 0下架, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint NOT NULL COMMENT 下单用户id, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1待接单 2配送中 3已完成 4已取消, address varchar(255) NOT NULL COMMENT 配送地址, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, pay_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order_item ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL, product_id bigint NOT NULL, product_name varchar(64) NOT NULL, product_price decimal(10,2) NOT NULL, quantity int NOT NULL DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 SQL 里有三个字段值得说明order_item 表里的 product_name 和 product_price 是下单瞬间的商品快照这是订单系统最容易被忽略的细节orders 表里的 order_no 用唯一索引约束避免并发生成重复单号status 用 tinyint 而不是枚举类型是因为 MyBatis-Plus 对枚举的处理需要额外配置用整型反而直观。创建时间用 DEFAULT CURRENT_TIMESTAMP 让数据库代劳代码里不需要再手动 set。数据库建好后实体类用 MyBatis-Plus 的注解风格来写这样可以省掉大量 XML 映射。我一般会在实体类里加一个 TableName 注解指定表名并开启驼峰映射。有一点要注意orders 这个表名在 MySQL 里不是保留字但 order 是所以表名最好统一用 orders 复数形式减少后续写 SQL 时被语法报错打断的尴尬。3. 后端接口与状态机让核心逻辑先跑起来3.1 登录与 openid先接微信身份再谈点单微信小程序和普通的 Web 后台登录方式不一样。小程序端不能自己造账号密码必须依靠 wx.login() 拿到的 code去微信服务器换取 openid。这个 openid 就是用户在系统里的唯一标识你的用户表里应该有一列 openid而不是存用户名密码。后端要做的是提供一个 POST /api/user/login 接口接收 code然后用 RestTemplate 调微信的 code2Session 接口拿到 openid 和 session_key。这里有个长期被忽略的坑很多教程把 session_key 也存进数据库其实完全没必要session_key 只用于解密手机号这类场景外卖系统用不到。我一般只存 openid然后自己生成一个 token 返回给小程序端后续请求带着 token 走。PostMapping(/login) public Result login(RequestBody LoginReq req) { String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code req.getCode() grant_typeauthorization_code; String resp restTemplate.getForObject(url, String.class); JSONObject obj JSON.parseObject(resp); String openid obj.getString(openid); User user userMapper.selectOne( new LambdaQueryWrapperUser().eq(User::getOpenid, openid)); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); } String token UUID.randomUUID().toString().replace(-, ); redis.set(token: token, user.getId().toString(), Duration.ofDays(7)); return Result.ok(token); }这段代码有三个参数需要根据你自己的环境调整appid 和 secret 在微信公众平台的小程序后台拿不能硬编码在代码里我把它们放在 application.yml 的外部配置里restTemplate 需要你自己 new 一个 Bean超时时间建议设 5 秒因为微信接口在高峰期延迟明显redis 用不用都行如果不引入 Redis可以把 token 存数据库表但用 Redis 的话后面做登录态失效和退出登录会方便很多。3.2 订单状态机必须显式定义从待支付到已取消外卖订单的状态流转远比想象中复杂。用户下单后先是待支付支付成功变成待接单商家接单后变配送中送达后变已完成。中途用户或商家可以取消。这里最容易犯的错误是把状态判断散落在各个 Service 方法里比如在接单方法里写 if (status 1)在配送方法里再写一次 if (status 1)后续改动一处漏掉另一处订单就走进死胡同。我的做法是在一个独立的 OrderStatus 类里把状态转移规则集中定义。每个状态能做什么、不能做什么都由一个方法说了算业务层只调用它。public class OrderStatus { public static final int UNPAID 0; public static final int PENDING 1; // 待接单 public static final int DELIVERING 2; public static final int FINISHED 3; public static final int CANCELLED 4; public static boolean canCancel(int status) { return status UNPAID || status PENDING; } public static boolean canConfirm(int status) { return status PENDING; } public static boolean canDeliver(int status) { return status PENDING; // 接单即开始配送 } }为什么不在数据库里加 CHECK 约束或者在接口层判断因为小程序端和商家管理端都会调用这类接口如果每个入口都写一遍判断必然出现漏网之鱼。集中在 OrderStatus 里至少保证所有查询状态的代码走同一套逻辑。另一个值得说明的点支付回调里修改状态时SQL 必须带上 WHERE status 旧状态的条件防止用户重复点击支付按钮导致状态被覆盖。这个可以用 UPDATE ... SET status 1 WHERE id ? AND status 0 来实现影响行数为 0 就说明状态已被其他请求修改。3.3 WebSocket 推送接单提醒别靠轮询商家端怎么知道有新订单最朴素的办法是前端定时 3 秒拉一次待接单接口但这样既费流量又会在订单少的时候产生大量无意义请求。外卖系统里更合适的方式是 WebSocket。小程序端对 WebSocket 的支持很成熟商家管理端如果也是小程序可以直接用 wx.connectSocket 连接。Spring Boot 整合 WebSocket 需要三步引入 spring-boot-starter-websocket 依赖、写一个继承 TextWebSocketHandler 的处理器、配置 WebSocket 注册端点。这里有个容易踩的细节WebSocket 连接是长连接不能每次都查数据库来判断用户身份所以连接建立时要通过 token 换取 user id并存到会话属性里后续推送直接找会话。Component public class OrderSocketHandler extends TextWebSocketHandler { private static final ConcurrentHashMapLong, WebSocketSession SESSIONS new ConcurrentHashMap(); Override public void afterConnectionEstablished(WebSocketSession session) { String token session.getAttributes().get(token).toString(); Long userId getUserIdByToken(token); session.getAttributes().put(userId, userId); SESSIONS.put(userId, session); } public static void sendToUser(Long userId, String message) { WebSocketSession session SESSIONS.get(userId); if (session ! null session.isOpen()) { session.sendMessage(new TextMessage(message)); } } }这段代码有两个点需要特别注意。第一WebSocketSession 不是线程安全的并发推送时要对 session 的 sendMessage 做同步不然偶发地报 ConcurrentModificationException。第二用户断线重连后旧的 session 要清理掉否则 map 里堆积失效连接内存慢慢涨上去。我在 afterConnectionClosed 里做了 SESSIONS.remove(userId)并且只在发送失败时清理单个 session这样逻辑比较稳。商家端有新订单的推送路径是用户下单成功后Service 里调用 OrderSocketHandler.sendToUser(商家userId, 订单JSON)商家小程序监听到消息后跳转到订单详情页。4. 小程序点单端下单链路与消息触达4.1 点单页的数据流商品、购物车与结算页之间怎么传小程序端页面拆成商品列表页、购物车页、确认订单页、订单详情页这四块。商品列表页用 wx.request 请求后端的 /api/product/list 接口拿到菜品数组后渲染到页面上。加入购物车的操作需要决定一个问题购物车数据放在小程序本地还是后端。我的建议是放在本地缓存里。原因有三第一用户加购是高频操作每点一次都请求后端会造成明显卡顿第二购物车是临时数据不涉及多端同步本地存储足够第三如果放在了后端用户没点结算就退出小程序购物车数据就成了脏数据。本地缓存的实现方式是用 wx.setStorageSync 把购物车数组存起来每次变更后重新写入读的时候用 wx.getStorageSync。但有个问题随之而来如果用户换了手机登录购物车就丢了。对外卖系统来说这个体验可以接受因为在确认订单页会让用户重新核对商品前端用本地购物车数据生成下单请求。真正不能本地化的是下单后的订单数据那必须走后端。4.2 下单接口对接从调起支付到回落确认页下单流程在小程序端分三步生成订单、调起支付、支付结果确认。第一步用户从购物车确认商品后前端把商品 id 列表和数量发给 POST /api/order/create后端计算总价并插入订单记录返回 orderId 和 orderNo。第二步前端拿到订单号后通过 wx.requestPayment 发起微信支付。这里注意你必须有微信支付商户号才能完整跑通支付很多毕设场景用模拟支付替代也就是前端点击支付按钮后请求一个后端接口把订单状态改为已支付。第三步是兜底逻辑。支付成功后后端不能等前端通知才知道结果而是由微信支付服务器回调你的后端接口。这就引出一个关键需求回调地址必须是一个公网可达的 HTTPS 地址本地 localhost 收不到回调。常见做法是用内网穿透工具把本地端口映射成一个公网域名然后把回调地址配置成这个域名。wx.request({ url: baseUrl /api/order/create, method: POST, data: { items: cartItems, address: address, remark: remark }, success(res) { if (res.data.code 0) { const orderId res.data.data.orderId; payForOrder(orderId); // 模拟支付或真实支付 } } }); function payForOrder(orderId) { wx.request({ url: baseUrl /api/order/pay/ orderId, method: POST, success(res) { if (res.data.code 0) { wx.redirectTo({ url: /pages/order/detail?id orderId }); } } }); }这段代码里最容易被忽略的是 baseUrl 的配置。开发环境下用本地局域网 IP真机调试时要改成公网地址每次换网络都要改很折腾。我习惯把 baseUrl 单独抽到 config.js 文件里并在文件顶部加注释说明当前环境指向哪个地址换环境时只改一处。4.3 订阅消息是外卖小程序的命门一次授权换一次性触达外卖场景里用户下单后需要知道「商家已接单」「骑手已出发」小程序端常见的实现是订阅消息。订阅消息的坑在于它不是永久的。微信规定用户每授权一次你只能给他发一条订阅消息。也就是说用户点了一次「允许」你只能推送一条模板消息发完就没了。这个限制直接影响系统设计。用户下单时需要让用户授权订单状态提醒如果订单经历接单、配送两个节点就需要两次授权。大多数毕设项目里只做一个节点——比如「接单通知」——然后在用户下单成功后立刻调 wx.requestSubscribeMessage 请求授权。wx.requestSubscribeMessage({ tmplIds: [模板ID_1], success(res) { if (res[模板ID_1] accept) { // 用户同意授权后端可以发一次订阅消息 wx.request({ url: baseUrl /api/order/subscribe, method: POST, data: { orderId: orderId } }); } } });模板 ID 需要到微信公众平台的小程序后台去申请不要随便抄别人文章里的模板 ID每个小程序的模板 ID 都不同。后端在商家接单时调一次 subscribeMessage.send 接口把用户的 openid、模板 ID、订单号和跳转页面传过去。这里要注意send 接口调用后如果用户已经取消了授权会返回 43101 错误码你的代码里要捕获这个错误别让它导致整个业务逻辑中断。5. 从本地到真机五个必踩的集成交付坑5.1 本地能出数据真机收不到登录态现象开发者工具里点单、支付、查订单一切正常一用手机预览就提示「登录已过期」或直接白屏。 原因开发者工具的「不校验合法域名」勾选让本地 http 请求全部放行真机的微信环境强制要求 HTTPS 和备案域名你的后端地址是 http://192.168.x.x被微信拦截了。 解决要么给后端配 HTTPS 证书并换正式域名要么在开发阶段用内网穿透工具把本地服务映射成 HTTPS 公网地址然后把小程序后台的 request 合法域名加上。这个坑几乎每个做小程序的人都会踩我建议在做登录功能之前就把 HTTPS 环境准备好别等联调再改。5.2 支付回调域名要求 HTTPS本地测试卡在这里现象模拟支付能走通真实支付一直不回调订单状态停在「待支付」。 原因微信支付回调 URL 必须是公网 HTTPS 且不能带端口本地服务根本无法收到回调。 解决开发阶段可以在付款接口里做「模拟支付」分支直接调本地接口把订单置为已支付上真实支付前再把回调地址配置到内网穿透工具生成的公网域名上。我用内网穿透做回调测试时还有一个细节穿透工具的免费域名经常变而支付回调地址一旦配置就不能频繁改所以我是在确认要测真实支付前才把回调地址改成穿透域名测试完再改回来。5.3 商家端关机用户订单卡死在「待接单」现象用户下单成功后商家端没在线订单一直是待接单用户反复催促但没有任何人处理。 原因WebSocket 推送要求接收端在线商家端退出小程序或断网后推送就丢了系统里也没有对应的超时或转单机制。 解决给订单加自动超时状态比如待接单超过 15 分钟自动标记为「已超时」同时把推送失败的订单写入一张待办表商家端下次上线时主动拉取。很多毕设不处理这个场景但如果你在论文里写了「商家端可以随时处理订单」这个超时补拉就会成为你答辩时的加分项。5.4 订阅消息点同意结果一个都不发现象用户测试时明明点了「允许」商家接单后却没有收到任何通知。 原因第一模板 ID 配错了第二订阅消息的发送接口必须在用户点击行为发生后的合理时间内调用订单支付的异步回调通道里发订阅消息经常被判定为「无有效订阅」第三用户授权一次只能发一条如果你是商家接单和配送出发各发一条一条授权根本不够。 解决下单成功后立刻请求订阅后端在下单请求里直接而不是在回调里记录订阅次数推送前先查一下剩余可用次数为 0 就不调用。如果你要实现「接单」和「配送」两条通知就让用户授权两次模板 ID 数组里放两个 ID两个都让用户确认。5.5 Redis 扣库存单机没问题压测一上就超卖现象开发时下单 10 次库存扣得准用压测工具模拟 50 并发下单同款菜品库存瞬间变成负数订单却全成功了。 原因代码里先 select 查库存再 update 减库存两个操作之间有间隙并发请求读到同一个旧库存然后一起做减法。 解决用一条带条件的 update 语句把「查」和「减」合并成一个原子操作影响行数为 0 再回滚订单。下面的 SQL 是这类系统里最常用的写法。UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity};这条语句的逻辑是MySQL 的行锁保证同一时刻只有一个事务能改这行数据stock quantity 让它在库存不足时直接不更新。如果 update 返回 0说明库存不够下单失败。代码里要注意的是先执行这条 update再插入订单数据如果把顺序反过来就会出现更新失败但订单已生成的问题。6. 验证与交付把实现和论文对上号的三个土办法6.1 用压测工具给下单接口灌 200 并发验证系统靠不靠谱最直接的方法是压测。我会把下单接口单独拿出来用 JMeter 建一个线程组设 200 个线程、每个线程循环 5 次看下单成功率。下单接口会同时扣库存所以这个压测同时验证了超卖问题是否真解决了。观察两个指标一个是异常率正常应该为 0一个是 TPS外卖点单系统即使做到 200 TPS 也已经超出毕设场景好几倍了。跑压测时注意数据库连接池配置。Spring Boot 默认的 HikariCP 最大连接数是 10200 并发时很多请求会排队等连接TPS 上不去是正常的。至少调到 50 再压但也不要无限调大数据库 CPU 会先撑不住。6.2 把论文的测试章节变成验收清单论文里一般有一章「系统测试」里面会写功能测试的用例表输入、预期结果、实际结果。这是最有价值的验收清单。我的做法是打开论文里的测试表把每一条用例按顺序抄到本地文档里然后在系统里一条条跑跑过的打勾。这招看起来土但非常有效。它不光是验收更是给自己准备答辩素材。答辩时老师问「你的系统测试做了哪些」你如果回答「我按论文里的测试用例完整跑了一遍其中 XX 个用例全部通过」比任何空话都有说服力。反过来如果某条用例在论文里写了但系统里实现不了那你在答辩前就需要决定是改代码还是改论文总之不能让它悬空。6.3 交付前最后一遍清测试数据、写环境说明、留可复现入口我见过好几个学弟的项目代码数据库里躺着几十条测试订单地址填的是「测试测试测试」商品图片全是本地随机图。交论文和源码之前我会把数据库的测试数据清干净只保留少量演示数据并给演示账号设置一个容易记的手机号。同时写一个 README把 JDK 版本、MySQL 初始化脚本路径、小程序 AppID 怎么配、baseUrl 在哪改这四件事写清楚。收尾的习惯是我踩过不少坑之后养成的每次交付源码前我会在自己电脑上照着 README 从零执行一遍如果能跑通才敢交出去跑不通就先改文档。复盘这套外卖系统时我最深的感受是论文能写得不完美但代码和文档之间不能有裂缝凡是论文里写到的功能要么实现要么在论文里删掉。这是做这类项目最值得记住的一条原则希望帮到你。本文还有配套的精品资源点击获取
简介一份围绕基于微信小程序的外卖点单系统展开的毕业论文文档面向计算机专业毕业生、毕设选题学生以及想了解Spring Boot后端与微信小程序前端联动开发的入门开发者。文档从外卖行业现状切入梳理了用户端浏览菜品、在线下单、订单状态确认与管理端菜品类型管理、菜品信息维护、订单处理等核心功能并对系统设计、数据库架构、服务器接口开发以及功能测试、性能测试、兼容性测试等环节作了详细说明能够帮助读者快速掌握此类毕设项目的整体流程与论文写法。资源包内只有一个docx文件大小约2.05MB包含摘要、关键词、目录、完整正文及参考文献可直接用于论文框架参考或学习摘录。目前已有207人学习适合需要完成外卖点单小程序设计与实现、或正在撰写相关课题论文的学生使用。1. 一篇 docx 论文真不是一套能直接抄的源码拿到「springboot基于微信小程序的外卖点单系统论文.docx」这个标题不少人的第一反应是去找源码压缩包。但这份交付物的核心其实是一个 Word 文档也就是说你手里握着的是一份「设计说得通」的需求与方案说明书而不是「能直接运行」的工程代码。这篇笔记要解决的就是这个落差手里只有论文、没有完整工程时怎么把 Spring Boot 后端和微信小程序端的前后端分离外卖系统一步步落地让实现和论文里的功能描述对得上号。我会按一个可复现的顺序来走先讲怎么从论文目录反推数据表再讲订单状态机这类后端硬骨头接着处理小程序端的点单和订阅消息最后是真机联调里的几个高频翻车点。整个过程不依赖任何你没见过的黑科技全是 Spring Boot 2.7 MyBatis-Plus MySQL 8.0 微信开发者工具这套常规组合。适合正在做外卖点单类毕设或练手项目、但手里只有论文草稿的开发者也适合想快速搭一套点单 Demo 再去补充业务细节的熟手。2. 先拆论文再写库从 docx 反推外卖系统的表结构2.1 从论文目录反推功能树一张接口清单就够了拿到论文后我习惯先跳过「绪论」和「技术介绍」这两章直接看系统分析、数据库设计和界面截图。原因很简单毕设论文的绪论部分大多是背景描述对写代码没有直接输入而功能需求那一章通常会把用户角色、功能模块和用例图画清楚。我拿到一篇典型的外卖点单系统论文时会先把目录里涉及功能的章节扫一遍提取出下面这类关键词用户注册登录、浏览菜品、购物车、下单结算、订单管理、商家接单、配送状态、历史订单。这些关键词会直接映射成一组 RESTful 接口清单比如 POST /api/order 是用户下单PUT /api/order/status 是商家更新订单状态。这一步看起来简单但很容易被人跳过。不少同学直接照着别人分享的源码建库结果发现论文里写的「菜品规格」功能在源码里根本不存在最后答辩时被问得下不来台。正确做法是把论文里提到但源码里没有的功能列成一张差异表哪怕先不做也要在数据库设计上留出扩展空间。我一般会在纸上画一张 5 列的表模块名、论文里的功能描述、对应接口路径、对应表、当前实现状态写完之后再动数据库。2.2 订单才是核心三张表的字段设计决定后面好不好写外卖点单系统里最容易设计错的是订单相关表。很多初学的人会把订单、订单明细、商品这三张表混在一起或者把商品价格和订单快照价格当成同一个字段。实际上商品价格会变但用户下单那一刻的价格必须被永久记录在订单明细里否则后续对账和订单详情页根本没法做。我常用的是三张核心表商品表 product、订单表 orders、订单明细表 order_item。外加购物车表 cart——虽然小程序端购物车也可以用本地缓存实现但考虑到论文里通常有「我的购物车」的数据库设计章节我选择把它落成表这样论文里的 E-R 图能对上。这三张表的字段设计有几个关键决策。第一orders 表里必须有 order_no 业务单号用时间戳加随机数生成不能直接用自增主键给用户看否则用户会拿单号去猜订单量。第二order_item 表里要冗余 product_name 和 product_price这两个字段在订单生成时从商品表复制过来后续商品改名、改价都不影响历史订单展示。第三orders 表里要有 status 字段我会用 tinyint 存状态值而不是直接存字符串这样状态机好写也方便前端映射。2.3 建表和实体的落地从 E-R 图到 SQL 不是照抄数据库设计章节的 E-R 图通常只画实体和关系不会告诉你每个字段的类型和长度。这里需要自己补齐约定id 用 bigint金额用 decimal(10,2)时间用 datetime状态用 tinyint。我自己整理出一套 SQL每次做这类系统都从这套模板改起。CREATE TABLE product ( id bigint NOT NULL AUTO_INCREMENT, name varchar(64) NOT NULL COMMENT 菜品名称, price decimal(10,2) NOT NULL COMMENT 售价, image varchar(255) DEFAULT NULL COMMENT 图片URL, category varchar(32) NOT NULL COMMENT 分类, stock int NOT NULL DEFAULT 0 COMMENT 库存, status tinyint NOT NULL DEFAULT 1 COMMENT 1上架 0下架, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint NOT NULL COMMENT 下单用户id, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1待接单 2配送中 3已完成 4已取消, address varchar(255) NOT NULL COMMENT 配送地址, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, pay_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order_item ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL, product_id bigint NOT NULL, product_name varchar(64) NOT NULL, product_price decimal(10,2) NOT NULL, quantity int NOT NULL DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 SQL 里有三个字段值得说明order_item 表里的 product_name 和 product_price 是下单瞬间的商品快照这是订单系统最容易被忽略的细节orders 表里的 order_no 用唯一索引约束避免并发生成重复单号status 用 tinyint 而不是枚举类型是因为 MyBatis-Plus 对枚举的处理需要额外配置用整型反而直观。创建时间用 DEFAULT CURRENT_TIMESTAMP 让数据库代劳代码里不需要再手动 set。数据库建好后实体类用 MyBatis-Plus 的注解风格来写这样可以省掉大量 XML 映射。我一般会在实体类里加一个 TableName 注解指定表名并开启驼峰映射。有一点要注意orders 这个表名在 MySQL 里不是保留字但 order 是所以表名最好统一用 orders 复数形式减少后续写 SQL 时被语法报错打断的尴尬。3. 后端接口与状态机让核心逻辑先跑起来3.1 登录与 openid先接微信身份再谈点单微信小程序和普通的 Web 后台登录方式不一样。小程序端不能自己造账号密码必须依靠 wx.login() 拿到的 code去微信服务器换取 openid。这个 openid 就是用户在系统里的唯一标识你的用户表里应该有一列 openid而不是存用户名密码。后端要做的是提供一个 POST /api/user/login 接口接收 code然后用 RestTemplate 调微信的 code2Session 接口拿到 openid 和 session_key。这里有个长期被忽略的坑很多教程把 session_key 也存进数据库其实完全没必要session_key 只用于解密手机号这类场景外卖系统用不到。我一般只存 openid然后自己生成一个 token 返回给小程序端后续请求带着 token 走。PostMapping(/login) public Result login(RequestBody LoginReq req) { String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code req.getCode() grant_typeauthorization_code; String resp restTemplate.getForObject(url, String.class); JSONObject obj JSON.parseObject(resp); String openid obj.getString(openid); User user userMapper.selectOne( new LambdaQueryWrapperUser().eq(User::getOpenid, openid)); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); } String token UUID.randomUUID().toString().replace(-, ); redis.set(token: token, user.getId().toString(), Duration.ofDays(7)); return Result.ok(token); }这段代码有三个参数需要根据你自己的环境调整appid 和 secret 在微信公众平台的小程序后台拿不能硬编码在代码里我把它们放在 application.yml 的外部配置里restTemplate 需要你自己 new 一个 Bean超时时间建议设 5 秒因为微信接口在高峰期延迟明显redis 用不用都行如果不引入 Redis可以把 token 存数据库表但用 Redis 的话后面做登录态失效和退出登录会方便很多。3.2 订单状态机必须显式定义从待支付到已取消外卖订单的状态流转远比想象中复杂。用户下单后先是待支付支付成功变成待接单商家接单后变配送中送达后变已完成。中途用户或商家可以取消。这里最容易犯的错误是把状态判断散落在各个 Service 方法里比如在接单方法里写 if (status 1)在配送方法里再写一次 if (status 1)后续改动一处漏掉另一处订单就走进死胡同。我的做法是在一个独立的 OrderStatus 类里把状态转移规则集中定义。每个状态能做什么、不能做什么都由一个方法说了算业务层只调用它。public class OrderStatus { public static final int UNPAID 0; public static final int PENDING 1; // 待接单 public static final int DELIVERING 2; public static final int FINISHED 3; public static final int CANCELLED 4; public static boolean canCancel(int status) { return status UNPAID || status PENDING; } public static boolean canConfirm(int status) { return status PENDING; } public static boolean canDeliver(int status) { return status PENDING; // 接单即开始配送 } }为什么不在数据库里加 CHECK 约束或者在接口层判断因为小程序端和商家管理端都会调用这类接口如果每个入口都写一遍判断必然出现漏网之鱼。集中在 OrderStatus 里至少保证所有查询状态的代码走同一套逻辑。另一个值得说明的点支付回调里修改状态时SQL 必须带上 WHERE status 旧状态的条件防止用户重复点击支付按钮导致状态被覆盖。这个可以用 UPDATE ... SET status 1 WHERE id ? AND status 0 来实现影响行数为 0 就说明状态已被其他请求修改。3.3 WebSocket 推送接单提醒别靠轮询商家端怎么知道有新订单最朴素的办法是前端定时 3 秒拉一次待接单接口但这样既费流量又会在订单少的时候产生大量无意义请求。外卖系统里更合适的方式是 WebSocket。小程序端对 WebSocket 的支持很成熟商家管理端如果也是小程序可以直接用 wx.connectSocket 连接。Spring Boot 整合 WebSocket 需要三步引入 spring-boot-starter-websocket 依赖、写一个继承 TextWebSocketHandler 的处理器、配置 WebSocket 注册端点。这里有个容易踩的细节WebSocket 连接是长连接不能每次都查数据库来判断用户身份所以连接建立时要通过 token 换取 user id并存到会话属性里后续推送直接找会话。Component public class OrderSocketHandler extends TextWebSocketHandler { private static final ConcurrentHashMapLong, WebSocketSession SESSIONS new ConcurrentHashMap(); Override public void afterConnectionEstablished(WebSocketSession session) { String token session.getAttributes().get(token).toString(); Long userId getUserIdByToken(token); session.getAttributes().put(userId, userId); SESSIONS.put(userId, session); } public static void sendToUser(Long userId, String message) { WebSocketSession session SESSIONS.get(userId); if (session ! null session.isOpen()) { session.sendMessage(new TextMessage(message)); } } }这段代码有两个点需要特别注意。第一WebSocketSession 不是线程安全的并发推送时要对 session 的 sendMessage 做同步不然偶发地报 ConcurrentModificationException。第二用户断线重连后旧的 session 要清理掉否则 map 里堆积失效连接内存慢慢涨上去。我在 afterConnectionClosed 里做了 SESSIONS.remove(userId)并且只在发送失败时清理单个 session这样逻辑比较稳。商家端有新订单的推送路径是用户下单成功后Service 里调用 OrderSocketHandler.sendToUser(商家userId, 订单JSON)商家小程序监听到消息后跳转到订单详情页。4. 小程序点单端下单链路与消息触达4.1 点单页的数据流商品、购物车与结算页之间怎么传小程序端页面拆成商品列表页、购物车页、确认订单页、订单详情页这四块。商品列表页用 wx.request 请求后端的 /api/product/list 接口拿到菜品数组后渲染到页面上。加入购物车的操作需要决定一个问题购物车数据放在小程序本地还是后端。我的建议是放在本地缓存里。原因有三第一用户加购是高频操作每点一次都请求后端会造成明显卡顿第二购物车是临时数据不涉及多端同步本地存储足够第三如果放在了后端用户没点结算就退出小程序购物车数据就成了脏数据。本地缓存的实现方式是用 wx.setStorageSync 把购物车数组存起来每次变更后重新写入读的时候用 wx.getStorageSync。但有个问题随之而来如果用户换了手机登录购物车就丢了。对外卖系统来说这个体验可以接受因为在确认订单页会让用户重新核对商品前端用本地购物车数据生成下单请求。真正不能本地化的是下单后的订单数据那必须走后端。4.2 下单接口对接从调起支付到回落确认页下单流程在小程序端分三步生成订单、调起支付、支付结果确认。第一步用户从购物车确认商品后前端把商品 id 列表和数量发给 POST /api/order/create后端计算总价并插入订单记录返回 orderId 和 orderNo。第二步前端拿到订单号后通过 wx.requestPayment 发起微信支付。这里注意你必须有微信支付商户号才能完整跑通支付很多毕设场景用模拟支付替代也就是前端点击支付按钮后请求一个后端接口把订单状态改为已支付。第三步是兜底逻辑。支付成功后后端不能等前端通知才知道结果而是由微信支付服务器回调你的后端接口。这就引出一个关键需求回调地址必须是一个公网可达的 HTTPS 地址本地 localhost 收不到回调。常见做法是用内网穿透工具把本地端口映射成一个公网域名然后把回调地址配置成这个域名。wx.request({ url: baseUrl /api/order/create, method: POST, data: { items: cartItems, address: address, remark: remark }, success(res) { if (res.data.code 0) { const orderId res.data.data.orderId; payForOrder(orderId); // 模拟支付或真实支付 } } }); function payForOrder(orderId) { wx.request({ url: baseUrl /api/order/pay/ orderId, method: POST, success(res) { if (res.data.code 0) { wx.redirectTo({ url: /pages/order/detail?id orderId }); } } }); }这段代码里最容易被忽略的是 baseUrl 的配置。开发环境下用本地局域网 IP真机调试时要改成公网地址每次换网络都要改很折腾。我习惯把 baseUrl 单独抽到 config.js 文件里并在文件顶部加注释说明当前环境指向哪个地址换环境时只改一处。4.3 订阅消息是外卖小程序的命门一次授权换一次性触达外卖场景里用户下单后需要知道「商家已接单」「骑手已出发」小程序端常见的实现是订阅消息。订阅消息的坑在于它不是永久的。微信规定用户每授权一次你只能给他发一条订阅消息。也就是说用户点了一次「允许」你只能推送一条模板消息发完就没了。这个限制直接影响系统设计。用户下单时需要让用户授权订单状态提醒如果订单经历接单、配送两个节点就需要两次授权。大多数毕设项目里只做一个节点——比如「接单通知」——然后在用户下单成功后立刻调 wx.requestSubscribeMessage 请求授权。wx.requestSubscribeMessage({ tmplIds: [模板ID_1], success(res) { if (res[模板ID_1] accept) { // 用户同意授权后端可以发一次订阅消息 wx.request({ url: baseUrl /api/order/subscribe, method: POST, data: { orderId: orderId } }); } } });模板 ID 需要到微信公众平台的小程序后台去申请不要随便抄别人文章里的模板 ID每个小程序的模板 ID 都不同。后端在商家接单时调一次 subscribeMessage.send 接口把用户的 openid、模板 ID、订单号和跳转页面传过去。这里要注意send 接口调用后如果用户已经取消了授权会返回 43101 错误码你的代码里要捕获这个错误别让它导致整个业务逻辑中断。5. 从本地到真机五个必踩的集成交付坑5.1 本地能出数据真机收不到登录态现象开发者工具里点单、支付、查订单一切正常一用手机预览就提示「登录已过期」或直接白屏。 原因开发者工具的「不校验合法域名」勾选让本地 http 请求全部放行真机的微信环境强制要求 HTTPS 和备案域名你的后端地址是 http://192.168.x.x被微信拦截了。 解决要么给后端配 HTTPS 证书并换正式域名要么在开发阶段用内网穿透工具把本地服务映射成 HTTPS 公网地址然后把小程序后台的 request 合法域名加上。这个坑几乎每个做小程序的人都会踩我建议在做登录功能之前就把 HTTPS 环境准备好别等联调再改。5.2 支付回调域名要求 HTTPS本地测试卡在这里现象模拟支付能走通真实支付一直不回调订单状态停在「待支付」。 原因微信支付回调 URL 必须是公网 HTTPS 且不能带端口本地服务根本无法收到回调。 解决开发阶段可以在付款接口里做「模拟支付」分支直接调本地接口把订单置为已支付上真实支付前再把回调地址配置到内网穿透工具生成的公网域名上。我用内网穿透做回调测试时还有一个细节穿透工具的免费域名经常变而支付回调地址一旦配置就不能频繁改所以我是在确认要测真实支付前才把回调地址改成穿透域名测试完再改回来。5.3 商家端关机用户订单卡死在「待接单」现象用户下单成功后商家端没在线订单一直是待接单用户反复催促但没有任何人处理。 原因WebSocket 推送要求接收端在线商家端退出小程序或断网后推送就丢了系统里也没有对应的超时或转单机制。 解决给订单加自动超时状态比如待接单超过 15 分钟自动标记为「已超时」同时把推送失败的订单写入一张待办表商家端下次上线时主动拉取。很多毕设不处理这个场景但如果你在论文里写了「商家端可以随时处理订单」这个超时补拉就会成为你答辩时的加分项。5.4 订阅消息点同意结果一个都不发现象用户测试时明明点了「允许」商家接单后却没有收到任何通知。 原因第一模板 ID 配错了第二订阅消息的发送接口必须在用户点击行为发生后的合理时间内调用订单支付的异步回调通道里发订阅消息经常被判定为「无有效订阅」第三用户授权一次只能发一条如果你是商家接单和配送出发各发一条一条授权根本不够。 解决下单成功后立刻请求订阅后端在下单请求里直接而不是在回调里记录订阅次数推送前先查一下剩余可用次数为 0 就不调用。如果你要实现「接单」和「配送」两条通知就让用户授权两次模板 ID 数组里放两个 ID两个都让用户确认。5.5 Redis 扣库存单机没问题压测一上就超卖现象开发时下单 10 次库存扣得准用压测工具模拟 50 并发下单同款菜品库存瞬间变成负数订单却全成功了。 原因代码里先 select 查库存再 update 减库存两个操作之间有间隙并发请求读到同一个旧库存然后一起做减法。 解决用一条带条件的 update 语句把「查」和「减」合并成一个原子操作影响行数为 0 再回滚订单。下面的 SQL 是这类系统里最常用的写法。UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity};这条语句的逻辑是MySQL 的行锁保证同一时刻只有一个事务能改这行数据stock quantity 让它在库存不足时直接不更新。如果 update 返回 0说明库存不够下单失败。代码里要注意的是先执行这条 update再插入订单数据如果把顺序反过来就会出现更新失败但订单已生成的问题。6. 验证与交付把实现和论文对上号的三个土办法6.1 用压测工具给下单接口灌 200 并发验证系统靠不靠谱最直接的方法是压测。我会把下单接口单独拿出来用 JMeter 建一个线程组设 200 个线程、每个线程循环 5 次看下单成功率。下单接口会同时扣库存所以这个压测同时验证了超卖问题是否真解决了。观察两个指标一个是异常率正常应该为 0一个是 TPS外卖点单系统即使做到 200 TPS 也已经超出毕设场景好几倍了。跑压测时注意数据库连接池配置。Spring Boot 默认的 HikariCP 最大连接数是 10200 并发时很多请求会排队等连接TPS 上不去是正常的。至少调到 50 再压但也不要无限调大数据库 CPU 会先撑不住。6.2 把论文的测试章节变成验收清单论文里一般有一章「系统测试」里面会写功能测试的用例表输入、预期结果、实际结果。这是最有价值的验收清单。我的做法是打开论文里的测试表把每一条用例按顺序抄到本地文档里然后在系统里一条条跑跑过的打勾。这招看起来土但非常有效。它不光是验收更是给自己准备答辩素材。答辩时老师问「你的系统测试做了哪些」你如果回答「我按论文里的测试用例完整跑了一遍其中 XX 个用例全部通过」比任何空话都有说服力。反过来如果某条用例在论文里写了但系统里实现不了那你在答辩前就需要决定是改代码还是改论文总之不能让它悬空。6.3 交付前最后一遍清测试数据、写环境说明、留可复现入口我见过好几个学弟的项目代码数据库里躺着几十条测试订单地址填的是「测试测试测试」商品图片全是本地随机图。交论文和源码之前我会把数据库的测试数据清干净只保留少量演示数据并给演示账号设置一个容易记的手机号。同时写一个 README把 JDK 版本、MySQL 初始化脚本路径、小程序 AppID 怎么配、baseUrl 在哪改这四件事写清楚。收尾的习惯是我踩过不少坑之后养成的每次交付源码前我会在自己电脑上照着 README 从零执行一遍如果能跑通才敢交出去跑不通就先改文档。复盘这套外卖系统时我最深的感受是论文能写得不完美但代码和文档之间不能有裂缝凡是论文里写到的功能要么实现要么在论文里删掉。这是做这类项目最值得记住的一条原则希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
