订餐系统源码实战：三端跑通与订单状态机改造指南

简介这是一份类似美团订餐系统的完整源码包包含系统管理后台Web端和移动端微信小程序端两部分。管理后台面向餐饮企业员工支持菜品、套餐、订单的维护管理移动端面向消费者实现在线浏览菜品、添加购物车、下单等核心流程。项目主要面向计算机相关专业的学生或企业员工适合用于毕业设计、课程设计或初期项目立项演示。压缩包共计392个文件大小约59.58MB以68个Java源码及编译后class文件为核心配合44个js、42个html、36个css构建前端页面还有86个png图片、xml/yml配置文件及SQL数据库脚本整套工程代码结构清晰便于直接导入开发工具运行。当前已有77人学习下载代码经过测试运行成功功能正常。资料附带项目说明文档可帮助读者快速理解系统分层与业务逻辑既适合新手实战练习也具备二次开发和功能扩展的参考价值。1. 一份订餐系统源码包先用十分钟判断值不值得往下跑一份类似美团订餐系统的源码包解压完通常是三块东西系统管理后台的 Web 端、微信小程序端应用、以及把它们串起来的后端服务。你拿到手的可能是课程设计作品也可能是外包项目更可能是从一个“免费源码大全”里扒下来的存货。判断它值不值得留下关键不是代码量而是三个端能不能对上后台维护的菜品、订单数据小程序真的能查到、能下单、能收到状态回传。这个闭环跑通了这套源码才是真实可用的。我按自己拿到这种源码包的习惯先拆结构、讲技术选型再带你按顺序把三端跑起来然后把订单状态机这类核心业务拆开说透。中间那批常见翻车点我会单独列出来最后给你一个值得做的改造方向。这篇东西面向的不是想读科普的人而是正准备拿它交作业、接外包、或者学一套完整前后端分离项目的从业者。2. 看懂这份订餐系统源码先拆结构再判断能复用多少2.1 解压后先别点“说明.doc”按目录结构建立全局认知拿到这种源码包我一般不会先打开 README 或“说明.doc”而是先扫一遍目录。原因很简单一个项目能不能跑起来数据模型和依赖配置比文档更能说明问题。文档可能是后补的但 SQL 脚本、接口路由、实体类字段不会骗人。订餐系统/ ├── docs/ # 说明文档、数据库设计、接口约定 ├── server/ # 后端服务 │ ├── src/main/java/ # 控制器、服务、数据访问 │ ├── src/main/resources/ # 数据源等配置 │ └── pom.xml # Maven 依赖 ├── admin-web/ # 系统管理后台Web端 │ ├── src/views/ # 菜品、订单、店铺页面 │ ├── src/api/ # 请求封装与接口定义 │ └── package.json ├── miniapp/ # 微信小程序端 │ ├── pages/ # 首页、购物车、订单、我的 │ ├── utils/request.js # 请求封装 │ └── app.json └── sql/ ├── init.sql # 建库建表 └── data.sql # 初始化演示数据这四类目录里docs 负责给你交代背景server 是业务中枢admin-web 是商家和平台运营操作入口miniapp 是 C 端用户点餐入口。注意这里的分工Web 端不是给普通用户用的它是系统管理后台管的是菜品上下架、订单处理和店铺配置小程序端才是用户每天打开的那个点餐界面。拿到目录后我做的第一件事是打开 sql/init.sql 扫一眼表数量重点关注orders、dish、sys_user这三张表。第二步是去 admin-web/src/api 和 miniapp/utils/request.js 里找接口路径确认前端调用的 URL 和后端控制器里的路由是否对得上。这一步值十五分钟能帮你避免下午才发现三端各调各的接口、白白浪费整个调试时间。2.2 技术栈为什么这样搭配管理后台选 Vue、小程序走原生或 uni-app这份源码最常见的技术栈组合是后端用 Spring Boot 或 Node.js 写 REST 接口管理后台用 Vue 加 Element UI小程序端用微信原生或 uni-app。我先把常见选型列成一张表方便你对照自己手里的这份包。端常见技术栈选型理由后端Spring Boot / Node.js Express订餐业务模型清晰适合用控制器、服务、持久层三层来表达系统管理后台Web端Vue 2/3 Element UI表格、表单、弹窗组件齐全适合订单、菜品这类中后台密集交互小程序端微信原生或 uni-app原生适合只做微信场景uni-app 可复用生成 H5 和未来多端应用为什么餐饮这类项目普遍选择微信小程序而不是 App因为用户不会为了点一份外卖去下载安装应用小程序扫码即用还能直接对接微信支付省掉单独申请支付渠道的流程。如果你盯着的是多端投放那用 uni-app 做底子的源码更划算一套代码未来还能编译成 android、iOS 甚至鸿蒙侧的应用但只要你只交付微信小程序原生小程序调试路径更短请求封装和页面堆栈都更直接。这套源码的架构通常是这样后端对外提供 HTTP JSON 接口管理后台和小程序都走同一个后端。登录状态一般用 JWT 或者 session订单状态由服务端统一维护。管理后台用路由守卫控制管理员权限小程序端用 wx.login 换取 openid 再生成登录态。理解了这条链路后面跑通三端时就不会被“为什么后台能登录、小程序却登录失败”这类问题卡住。2.3 五个决定“能不能用”的关键设计点拿到源码后从头到尾读代码不现实我只看五个关键设计点。这五点决定了这套系统是“玩具”还是“能交付”的底子。第一订单状态机。订餐系统的核心不是页面而是订单从待付款到已完成的状态流转。订单表里的 status 字段如果只是随便存一个整数没有枚举定义也没有流转校验那这套系统大概率是半成品。完整的闭环应该包含这样一组状态10 待付款 → 20 待接单 → 30 制作中 → 40 配送中 → 50 已完成 10 待付款 → 60 已取消用户主动取消 20 待接单 → 60 已取消商家超时拒单有了这个状态机管理后台才能根据不同的状态渲染不同的操作按钮小程序端才能正确显示“催单”“取消”“确认收货”入口。第二菜品上下架与规格。菜品表必须要有 status 字段和 stock 字段。上下架只是翻转 status不是删数据小程序首页查询时只展示 status1 的菜品。如果这份源码里菜品没有库存字段订单流程只能停留在“点着玩”的程度。第三用户身份体系。订餐系统至少有四类角色超级管理员、商家管理员、配送员、C 端用户。管理后台要区分超级管理员和商家管理员配送员要有自己的配送任务列表小程序端用户是另一套登录体系。角色不同接口权限就不同。源码里如果没有 role 字段或者权限注解后期补权限会非常痛苦。第四购物车。最常见的做法是小程序端用 wx.setStorageSync 存本地购物车优点是流畅缺点是换设备不同步。少数源码会把购物车放服务端好处是用户换设备购物车还在但每次加菜都请求接口体验会稍慢。我看源码时重点看提交订单的接口要不要传完整的菜品列表如果只需要传 dishId 和数量那购物车在本地如果要传菜品名称、价格那么前端可能伪造价格这是安全隐患。第五微信支付回调。真实上线的订餐系统必然要处理微信支付。支付流程是用户在小程序端发起支付后端先生成支付参数微信支付成功后异步通知后端接口后端再把订单状态从待付款改成待接单。源码里如果只有“模拟支付”的按钮说明商家可以演示流程但无法直接上线。你要做好自己接支付回调的准备。3. 从 ZIP 到三端跑通环境准备、数据库初始化与启动顺序3.1 环境准备JDK、Node、MySQL 与微信开发者工具跑一套三端项目环境搭错是后面所有坑的源头。我通常按这份清单准备版本建议尽量贴着源码的依赖来别一上来就装最新版。软件版本建议用途JDK8 或 11后端若用 Spring Boot8/11 最稳Node.js14/16 LTS管理后台 npm 依赖MySQL5.7 或 8.0用户、菜品、订单数据Redis根据源码选装若引用了缓存或服务端购物车微信开发者工具最新稳定版运行小程序端你从源码包里先找 pom.xml后端用 Java或 package.json后端用 Node确认版本号再决定装什么。常见问题就是 Node 版本太高导致 node-sass 编译失败、MySQL 版本太旧导致 utf8mb4 乱码。版本对齐这一步做到位后面能省大把时间。3.2 数据库初始化先跑 SQL再改连接串数据库是整套系统的地基。先把 init.sql 导进去再动服务端配置。很多源码包里的 SQL 脚本是分两个文件的init.sql 建表data.sql 灌演示数据。演示数据里通常有默认账号、默认店铺、默认菜品强烈建议保留它能让小程序端和管理后台第一次登录就有东西可看。-- 创建订餐系统数据库字符集必须用 utf8mb4否则中文名和微信昵称会变成 ??? CREATE DATABASE IF NOT EXISTS ordering DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE ordering; -- 假设源码包在 /Users/you/order/sql 下导入建表脚本 SOURCE /Users/you/order/sql/init.sql; -- 导入演示数据 SOURCE /Users/you/order/sql/data.sql;这段 SQL 的逻辑说明utf8mb4 是 MySQL 里支持 emoji 和生僻字的字符集订餐系统里用户的微信昵称、收货地址、菜品描述都可能出现这些字符用老旧的 utf8 一定会出问题。SOURCE 是 MySQL 命令行里的导入指令注意路径要写绝对路径或者提前用cd切到 sql 目录下再执行。导入完成后去 sys_user 表里查一下默认管理员账号SELECT id, username, password, role, status FROM sys_user WHERE role ADMIN;执行这条查询的目的是确认默认账号密码是否存在。密码字段通常是 MD5 或 BCrypt 加密后的密文别花时间破解去 docs 或者 data.sql 里找明文密码找不到就直接把这条记录的密码改成一个你知道的加密值。比如用 MD5 加密“admin123”然后 UPDATE 进去。3.3 后端服务启动改配置文件比写代码更重要后端是整个系统最先启动的一环。数据库没起、配置文件不对后面 Web 端和小程序端全是接口报错。以 Spring Boot 版本的源码为例常见启动命令如下# 进入后端目录跳过测试打包 cd server mvn clean package -DskipTests # 启动后端服务 java -jar target/ordering-server*.jar如果源码后端是 Node.js 写的命令就换成npm install node app.js或npm run dev关键点都一样先找到配置文件改数据库连接。Spring Boot 项目里这份配置一般在src/main/resources/application.ymlspring: datasource: url: jdbc:mysql://localhost:3306/ordering?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver server: port: 8080这几个参数的含义url 里的 ordering 是数据库名必须和建库语句里的名字一致characterEncodingutf8 保证中文正常传输serverTimezoneAsia/Shanghai 解决 MySQL 8.0 的时区报错password 换成你自己数据库的密码。端口 8080 如果被占用改成 8081 也行但后面管理后台的代理地址要同步改。启动成功后随手做一个接口自检curl http://localhost:8080/api/health如果返回 JSON 里带status: ok之类的标识说明后端已经起来了。如果 curl 不通看启动日志里的报错八成是数据库密码错误、端口占用或 Redis 没启动。3.4 Web 管理后台启动代理和环境变量后端起来了接着启动系统管理后台Web 端。它本质是一个 Vue 工程用 npm 管理依赖开发模式下通过 devServer 把请求代理到后端。cd admin-web npm install npm run devnpm install 如果卡在某个包上先确认 Node 版本和 package.json 里的要求是否一致。装完后运行 dev默认端口一般是 8081。这里的关键配置在 vue.config.js 里常见的写法是// vue.config.js —— 开发环境代理配置 module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, // 转发到后端 changeOrigin: true } } } }这段配置解决的是开发环境跨域问题管理后台页面请求/api/login时devServer 会把它转发到后端的http://localhost:8080/api/login。如果你改了后端端口target 要同步改。启动完成后打开http://localhost:8081用刚才查到的管理员账号登录看到商品列表和订单列表说明 Web 端和后端已经打通。3.5 小程序端跑起来统一改请求封装里的 baseURL小程序端是三端里最容易出问题的一环因为它的运行环境特殊。微信开发者工具里可以模拟请求但真机预览时手机不能访问你电脑上的 localhost。你需要把utils/request.js里的 baseURL 从 localhost 改成电脑在局域网里的 IP。// utils/request.js —— 小程序全局请求封装 const BASE_URL http://192.168.1.10:8080/api // 改成你电脑的局域网 IP const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json }, success: (res) { if (res.statusCode 200) { resolve(res.data) } else { reject(res) } }, fail: reject }) }) } module.exports request这段封装里BASE_URL 是要你改的核心参数。在微信开发者工具里导入整个 miniapp 目录AppID 可以用测试号然后在“详情-本地设置”里勾选“不校验合法域名”开发模式下就能用 http 访问本地接口。手机和电脑连同一个 WiFi把 localhost 换成电脑 IP真机预览才能通。三端跑通后做一轮最小验证Web 管理后台登录成功后台新建一个菜品小程序首页下拉刷新能看到小程序提交一个订单管理后台订单列表出现新单。这四条走通这套订餐系统源码就属于“能用了”。4. 打通业务闭环订单状态机、菜品上下架与权限设计4.1 订单状态机的表设计与流转约束订单是整个订餐系统的数据中枢。很多源码看起来功能齐全但订单状态只是随便存一个数字更新时直接 set 新值不管旧值是什么这就会导致重复接单、取消后还能配送之类的逻辑漏洞。我在评估一套源码时第一件事就是看订单表的态设计与更新方式。CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号建议按日期随机数生成, user_id bigint(20) NOT NULL COMMENT 下单用户, shop_id bigint(20) NOT NULL COMMENT 店铺ID, status tinyint(4) NOT NULL DEFAULT 10 COMMENT 10待付款 20待接单 30制作中 40配送中 50已完成 60已取消, total_amount decimal(10,2) NOT NULL COMMENT 订单总额, address varchar(255) NOT NULL COMMENT 收货地址, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;这张表的设计里status 用 tinyint 而不是字符串是因为数字类型占空间小、索引效率高同时要求代码里必须有对应的枚举或常量类去解释这些数字。表上给 user_id 和 status 建索引是因为查询场景集中在“用户查自己的订单”和“商家按状态筛选订单”。状态流转更关键的是更新方式。常见做法是在 Service 层用一个 CAS 风格的条件更新而不是先查出来再改// 商家接单操作期望订单当前是 20 待接单目标改到 30 制作中 int updated orderMapper.compareAndSetStatus(orderId, 20, 30); if (updated 0) { throw new IllegalStateException(订单状态已变化请刷新后重试); }这里compareAndSetStatus的 SQL 本质是UPDATE orders SET status 30 WHERE id ? AND status 20。如果有两个管理员同时点接单只有一个请求能更新成功另一个 updated 为 0被挡在门外。这个设计能避免很多并发场景下的脏数据。4.2 菜品上下架与规格管理后台最核心的操作订餐系统的菜品管理核心动作就两个上架和下架。很多新手把“下架”做成“删除”这是错的。菜品一旦删除历史订单里的商品名和价格就变成悬空的引用。正确的做法是设计一个 status 字段下架只是把它置为 0。CREATE TABLE dish ( id bigint(20) NOT NULL AUTO_INCREMENT, shop_id bigint(20) NOT NULL COMMENT 所属店铺ID, category_id bigint(20) NOT NULL COMMENT 分类ID热菜/凉菜/主食, name varchar(100) NOT NULL COMMENT 菜品名称, price decimal(10,2) NOT NULL COMMENT 售价, image varchar(255) DEFAULT NULL COMMENT 图片URL, stock int(11) DEFAULT 0 COMMENT 库存, status tinyint(4) DEFAULT 1 COMMENT 1上架 0下架, sort int(11) DEFAULT 0 COMMENT 排序权重, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品表;做下架操作的 SQL 很简单UPDATE dish SET status 0 WHERE id ?;不用 DELETE原因有两个第一历史订单需要保留菜品当时的名称和价格快照第二运营人员可能只是暂时停售第二天还要上架。在小程序端首页的查询语句里一定要带WHERE status 1这个条件否则后台一改状态小程序端就会出现已下架菜品还在卖的情况。4.3 小程序端购物车与下单缓存策略与提交方式小程序端的购物车实现最省事且常见的是本地缓存方案。用 wx.setStorageSync 把购物车数据存在用户手机里好处是响应快不占用服务端资源。一个最小可用的购物车封装是这样的// utils/cart.js —— 基于本地存储的小程序购物车 const CART_KEY cart function getCart() { return wx.getStorageSync(CART_KEY) || {} } // 加入购物车dish 里至少要包含 id、name、price function addToCart(dish, count 1) { const cart getCart() if (cart[dish.id]) { cart[dish.id].count count } else { cart[dish.id] { id: dish.id, name: dish.name, price: dish.price, count } } wx.setStorageSync(CART_KEY, cart) } module.exports { getCart, addToCart }这段代码里购物车以菜品 id 为 keycount 是数量。注意一个关键设计本地缓存的 price 只用于界面展示真正下单时不能信任它。小程序端提交订单时正确的做法是只传 dishId 和 count后端重新查数据库里的实时价格并计算总价。如果源码里的下单接口直接接受前端传的 totalAmount那要自己加一道服务端价格重算的逻辑否则用户改一下请求参数就能低价下单。本地缓存购物车有个天然缺陷菜品在后台改价或下架后用户手机里的购物车还是旧数据。所以提交订单接口要在后端校验每个菜品是否上架、库存是否足够、价格是否一致发现问题就返回明确提示而不是让用户支付失败后骂骂咧咧关掉小程序。4.4 Web 管理后台的订单列表、状态操作与角色权限管理后台的订单页面本质是根据订单状态渲染不同操作按钮。用 Vue 加 Element UI 的话核心逻辑很简单el-table :dataorders el-table-column proporderNo label订单号 / el-table-column proptotalAmount label金额 / el-table-column label状态 template slot-scope{ row } el-tag :typestatusTag(row.status){{ statusText(row.status) }}/el-tag /template /el-table-column el-table-column label操作 template slot-scope{ row } el-button v-ifrow.status 20 typeprimary sizesmall clickacceptOrder(row.id) 接单/el-button el-button v-ifrow.status 30 typesuccess sizesmall clickmarkDelivering(row.id) 开始配送/el-button /template /el-table-column /el-table这段模板里的 v-if 就是状态驱动 UI 的核心订单在 20 待接单状态才显示“接单”按钮在 30 制作中状态才显示“开始配送”。前端按状态渲染是体验问题真正的权限校验必须在后端接口里做。比如一个商家管理员不能操作另一个店铺的订单这就要在后端根据当前登录用户的 shop_id 过滤数据而不是只靠前端传一个订单号。角色权限这块套完整的订餐系统应该有这样的划分角色Web 管理后台可操作小程序端能力超级管理员管理店铺、账号、全局订单无商家管理员菜品上下架、订单处理、营业统计查看店铺经营数据配送员查看配送任务确认取餐、送达C 端用户无浏览、下单、付款、查订单拿到源码后去后端的接口配置里看有没有做角色拦截。如果所有接口都只是登录就能调那这个权限体系就等于没有需要自己补。补权限的优先级是支付回调、订单状态更新、菜品上下架这些接口必须先拦住。5. 三端联调避坑跑这套订餐系统最容易翻车的 5 个地方5.1 小程序请求连不上本地后端不要用 localhost 或 127.0.0.1现象微信开发者工具里模拟器请求接口一直超时或者真机预览时页面转圈后报request:fail。工具里明明能打开后端文档但小程序就是连不上。原因小程序运行在手机或模拟器里它访问的localhost指向的是小程序所在的设备而不是你的电脑。开发者工具模拟器比较特殊部分情况下 localhost 能通但真机预览必然失败。另外后端如果监听了 127.0.0.1局域网内其他设备也访问不到。解决把小程序请求封装里的 baseURL 改成电脑的局域网 IP例如http://192.168.1.10:8080/api然后确认电脑防火墙放行了 8080 端口。后端启动时如果用的是 Spring Boot可以在启动参数里加--server.address0.0.0.0让服务监听所有网卡地址。最后在微信开发者工具“详情-本地设置”里勾选“不校验合法域名”开发模式才能用 http 访问。5.2 npm install 报错node-sass 或 node-gyp 编译失败现象在 admin-web 目录下执行npm install报错信息里出现node-sass、python、Visual Studio、gyp这类关键词安装过程在中途直接中断。原因node-sass 是一个需要在安装时编译原生模块的依赖包它和你本地的 Node 版本强绑定。Node 版本太新或太旧都会导致找不到对应二进制文件而触发源码编译编译环境又缺 Python 或 C 构建工具于是必然失败。解决先看 package.json 里 node-sass 的版本换成它对应的 Node 大版本比如 node-sass4.14 配 Node 14node-sass7.0 配 Node 16。如果不想折腾版本直接把 node-sass 从 package.json 里替换成sass: ^1.32.0代码里import的写法基本不用改安装速度还更快。装依赖慢的话把 npm 镜像源切到国内源能省下大量等待时间。5.3 SQL 导入失败utf8mb4 乱码或索引长度超限现象执行 init.sql 时报错Specified key was too long或者导入成功后查表中文全变成???。原因Specified key was too long通常是索引字段长度超过 767 字节MySQL 5.6 及以下版本对 varchar 索引长度有限制。中文乱码则是因为建库时用了utf8而它最多存 3 字节的字符微信昵称里的 emoji 或者生僻字直接写入失败或变成问号。解决把 MySQL 升到 5.7 以上建库语句用utf8mb4。如果索引长度还是报错把 varchar(255) 的字段改成 varchar(191) 或降低索引字段的长度。导入前检查 SQL 文件开头有没有SET NAMES utf8mb4没有就补上。这样处理后中文、emoji、生僻字都能正常存取。5.4 管理后台改了订单状态小程序端还是旧的状态没有推给用户现象在 Web 管理后台点击“接单”订单状态变成“制作中”但用户的小程序在订单页下拉刷新后看到的还是“待接单”。原因小程序端订单列表大概率走了缓存或者只在 onLoad 时请求了一次。用户从小程序订单列表切到订单详情再从详情返回列表如果列表页没有重新拉取接口页面展示的还是内存里那份旧数据。后端没有主动推送能力前端也没做轮询或下拉刷新逻辑。解决在小程序订单列表页的onShow生命周期里重新请求订单列表而不是只在onLoad里拉一次。如果订单状态需要实时更新可以在订单详情页加一个简单的轮询定时器每隔 5 秒拉一次最新状态用户看到的状态就会跟着后台操作走。5.5 端口占用或服务启动到一半就崩现象执行java -jar或npm run dev后日志打到一半就退出提示Port 8080 was already in use或者没有报错但服务就是访问不了。原因最常见的是前一次启动的后端没有关闭或者电脑上其他程序占用了 8080/8081 端口。另一个场景是后端启动到一半崩了其实是因为它依赖的 Redis 没启动、数据库连接串不对只是 Spring Boot 的启动日志太长报错被淹没在中间。解决按顺序启动先确认 MySQL 和 Redis 起来了再启动后端启动完后用curl做一次健康检查通了再启动 Web 端和小程序端。遇到端口占用的在 Mac 上用lsof -i :8080在 Windows 上用netstat -ano | findstr 8080查出占用进程关掉或换端口否则后面所有接口报错都会让你怀疑是代码问题。6. 上线前的验证方法以及一次值得做的库存扣减改造把三端跑通只是开始真正让这套订餐系统“敢上线”的是验证核心链路在高并发下不会出问题。我拿到源码后的第一件事不是加功能而是按这张清单过一遍验证场景验证内容登录与权限管理员、商家、用户各角色只能访问自己该访问的接口菜品上下架上架后小程序可见下架后小程序刷新不可见下单与库存库存扣减正确超卖时订单创建失败接单并发两个管理员同时接单只有一个成功订单状态已取消的订单不能再次进入制作中金额计算修改前端传参金额后端仍按数据库价格结算其中必须做的一次改造是把“先查库存再扣减”改成“条件更新扣减”。很多源码的库存逻辑是select stock from dish where id ? if stock 0: update dish set stock stock - 1这段逻辑在单用户下没问题但并发下单时两个请求都查到了库存为 1都判断可以扣最后库存变成 -1这就是超卖。正确做法是改成数据库条件更新UPDATE dish SET stock stock - 1 WHERE id ? AND stock 0;执行这条 SQL 后如果影响行数是 1说明扣减成功影响行数是 0说明库存不足直接提示用户“商品已售罄”。这个改动的成本只有几行代码但它把库存从“可能超卖”变成“一定安全”是我做订餐项目时一定会补的一刀。做完这些验证和改造这套类似美团订餐系统的源码就从一个“能演示”的项目变成了一个“能交付”的底子。它教会你的不只是 Vue、小程序和 Spring Boot 三端怎么拼更是订单状态机、权限体系、并发控制这些真正决定系统能不能上线的东西。我自己的习惯是每拿到一套三端源码先按这个顺序折腾一遍把它当成练兵场改完库存扣减再顺手加上支付回调的模拟这套功夫就落到自己手里了。希望帮到你。本文还有配套的精品资源点击获取