拓冰网站定制 
简介完整版微信外卖小程序系统源码与数据库打包于一个zip压缩包内面向需要搭建或二次开发外卖平台的开发者、商家及技术学习者。系统基于Java语言开发集商家管理、骑手调度、用户下单、订单跟踪等核心模块于一体前后端完整并支持微信支付等常见接口适用于餐饮、商超、堂食等场景。压缩包共包含2825个文件以日志文件、FastReport报表模板fr3、PDF文档及动态链接库为主日志可供运行排查fr3报表模板方便订单统计展示另有少量配置和图片资源大小约27.61MB便于本地部署与代码阅读。附带数据库设计涵盖用户、商家、商品、订单、骑手等多张数据表通过外键关联保障数据一致性整体目录结构清晰便于按模块对照开发。目前已有908人学习下载适合具备一定Java基础的中高级开发者在真实业务中参考复用。1. 一套 Java 写的微信外卖小程序源码能直接接手当二开基座吗先说明一点标题里的 JAVE 是 Java 的笔误这类外卖源码的实际技术栈几乎都是 Java 系后端用 Spring Boot 提供接口MySQL 存全部业务数据微信小程序承担用户端再配上能登录的管理后台去添加商家、骑手账号。“前后端都有”这几个字才是这套源码最值钱的地方——你拿到手不是一堆碎片而是一条能跑通的业务闭环用户能看菜下单商家能接单上架骑手能抢单配送管理员能在后台维护人和货。它适合三类人有 Java 基础想二开做校园外卖、社区配送的开发者需要完整前后端工程写毕业设计的学生以及想用最低成本快速验证外卖小程序商业模型但不想从零搭一个月的创业者。下面我从架构拆解讲到部署避坑最后给一份能直接抄的交付前验证清单。2. 拆开源码看架构前后端分离、四端工程与核心表设计拿到源码第一件事不是急着启动而是先把目录结构看清楚。常见做法是后端打成一个 Spring Boot 工程前端按“端”拆分目录或拆成多个小程序工程管理后台单独用浏览器访问。先把工程边界摸清后面改代码才不至于一动手就迷路。2.1 前后端分离到底分了哪些“端”用户端、商家端、骑手端与管理后台这套系统的“功能强”主要体现在四个角色各有一套入口而不是登录进去切来切去。多数源码会把前端拆成这几个部分端常见技术栈核心职责与后端的交互方式用户端小程序原生微信小程序或 uni-app浏览商家、加购、下单、支付、确认收货wx.request 调后端 REST 接口商家端小程序原生微信小程序菜品上下架、订单提醒、接单/拒单轮询或 WebSocket 接收新订单通知骑手端小程序原生微信小程序抢单、取餐、送达、上传位置调用配送相关接口管理后台Vue / Element UI 或类似前端框架添加商家、添加骑手、审核、数据统计axios 调后端管理接口为什么要前后端分离而不是做成一个大网页因为外卖场景里四个角色对界面和操作路径的要求完全不一样。用户在手机上追求下单快商家需要同时看到多个新订单并快速处理骑手要的是地图和单子列表管理员则要坐在电脑前维护数据。四个端独立演进也方便你只二改其中一部分。2.2 数据库怎么支撑一次完整的外卖下单商户、菜品、订单、配送的六张核心表数据库是这套源码的骨架我一般拿到源码会先建一个空库把 SQL 导进去然后用可视化工具把表关系画出来看。常见核心表大致是这个结构下面的建表语句做了精简但字段设计思路和完整源码基本一致-- 用户表存微信用户、管理员、商家、骑手共用的基础账号信息 CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) DEFAULT NULL COMMENT 微信openid, phone varchar(20) DEFAULT NULL COMMENT 手机号, username varchar(50) DEFAULT NULL COMMENT 后台登录账号, password varchar(100) DEFAULT NULL COMMENT 后台登录密码, role tinyint(4) DEFAULT 0 COMMENT 0用户 1商家 2骑手 3管理员, status tinyint(4) DEFAULT 1 COMMENT 1正常 0禁用, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 商家表一条记录对应一个入驻外卖平台的店铺 CREATE TABLE merchant ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) DEFAULT NULL COMMENT 关联user表, name varchar(100) DEFAULT NULL COMMENT 店铺名称, notice varchar(255) DEFAULT NULL COMMENT 公告, delivery_fee decimal(10,2) DEFAULT 0.00 COMMENT 配送费, status tinyint(4) DEFAULT 1 COMMENT 1营业 0打烊, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 菜品表归属某个商家上下架状态直接决定用户在端上能不能看到 CREATE TABLE dish ( id bigint(20) NOT NULL AUTO_INCREMENT, merchant_id bigint(20) DEFAULT NULL, category_id bigint(20) DEFAULT NULL COMMENT 分类id, name varchar(100) DEFAULT NULL, price decimal(10,2) DEFAULT NULL, image varchar(255) DEFAULT NULL COMMENT 图片URL, shelf_status tinyint(4) DEFAULT 1 COMMENT 1上架 0下架, stock int(11) DEFAULT 0 COMMENT 库存, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单主表一次下单生成一条记录状态机贯穿整个配送流程 CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) DEFAULT NULL COMMENT 订单号, user_id bigint(20) DEFAULT NULL, merchant_id bigint(20) DEFAULT NULL, total_amount decimal(10,2) DEFAULT NULL, status tinyint(4) DEFAULT 0 COMMENT 0待支付 1待接单 2配送中 3已完成 4已取消 5退款, address varchar(255) DEFAULT NULL, remark varchar(255) DEFAULT NULL, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单明细表一个订单对应多条菜品记录 CREATE TABLE order_detail ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) DEFAULT NULL, dish_id bigint(20) DEFAULT NULL, dish_name varchar(100) DEFAULT NULL, price decimal(10,2) DEFAULT NULL, quantity int(11) DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 配送表订单被骑手认领后配送状态和位置信息在这里更新 CREATE TABLE delivery ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) DEFAULT NULL, rider_id bigint(20) DEFAULT NULL COMMENT 骑手user_id, status tinyint(4) DEFAULT 0 COMMENT 0待抢 1已接单 2取餐 3送达, lat decimal(10,6) DEFAULT NULL COMMENT 骑手纬度, lng decimal(10,6) DEFAULT NULL COMMENT 骑手经度, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这套表的精髓在于“资金、货、人”分开存。订单主表只管状态和金额明细表管具体买了什么配送表管履约过程商家和骑手通过 user_id 关联到 user 表而不是各自维护一套登录体系。做数据库增删改查时思路就清晰下单一笔事务要同时写 orders、order_detail、dish 库存和 cart 购物车任何一步失败整个事务回滚线上才不会出现“用户付了钱商家看不到单”的诡异问题。2.3 权限模型一个用户如何变成商家或骑手管理后台又是怎么“添加”出来的标题特别强调“可添加商家、骑手”这里的关键不是写一行 INSERT而是后台添加完之后新商家能立刻用自己的账号登录并管理店铺。常见的设计是 user 表统一存账号role 字段区分身份再用业务扩展表补齐信息。管理后台添加商家的本质是两步先插 user 表生成一个账号再插 merchant 表把账号和店铺绑定。-- 查询某微信用户身份时通常要把基础账号和业务身份连查 SELECT u.id, u.role, m.id AS merchant_id, m.name AS merchant_name FROM user u LEFT JOIN merchant m ON m.user_id u.id WHERE u.openid #{openid};这个连查在登录接口里几乎是标配。用户进入小程序先 wx.login 换 openid后端拿着 openid 查一次用户返回角色如果 role 是商家前端跳商家工作台如果 role 是骑手跳骑手接单页如果没有记录就默认走普通用户流程。管理后台“添加骑手”同理插一条 user 记录再插骑手扩展表初始密码常见的做法是后台生成一个随机密码第一次登录后要求修改避免账号裸奔。权限模型最怕的坑是角色和业务数据脱节删了 user 表记录却忘记删 merchant 或 rider 扩展表会导致登录后无法加载店铺最后只能手动清垃圾数据。3. 本地跑通最小系统导入数据库、改配置、启动后端、小程序联调“系统稳定”这种描述只有在你亲眼看到它跑起来之后才有意义。本地跑通是整个二开过程的地基我把流程压成四步装环境、导 SQL 改配置、启动后端、小程序联调。每一步失败都有固定解法别硬闯。3.1 环境准备JDK、Maven、MySQL 与微信开发者工具的最小版本组合常见做法是 JDK 1.8 或 11、Maven 3.6 以上、MySQL 5.7 或 8.0、微信开发者工具最新稳定版。如果源码用了 MyBatis-Plus 和 LombokIDEA 里还要装 Lombok 插件否则编译直接报“找不到 getter/setter”。这里先检查一个最容易翻车的点JDK 版本太高而源码是基于 JDK 8 写的Maven 编译可能报 “无效的发行版本”。不用急着升 JDK先看 pom.xml 里 java.version 写的是多少保持一致再跑。# 检查本机环境确认三个基础工具就位 java -version mvn -v mysql --version没有 JDK 或 Maven 时去对应官网下载安装包配置环境变量即可。MySQL 安装完记得确认服务已启动Windows 下常见问题是端口被占用或 root 密码复杂度不符合要求这些和源码本身无关但会浪费你大量排查时间。3.2 导入 SQL 与修改 application.yml四个不改就启动失败的参数用可视化工具新建一个空库字符集选 utf8mb4然后把源码附带的 .sql 文件整体导入。导入成功后重点检查表数量是否和源码自带数据库说明一致如果少了几张表多半是 SQL 文件执行到一半报错中断需要按错误提示修正后重新导入。之后打开后端的 application.yml重点改这几项server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/waimai?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver wx: appid: 你的小程序AppID secret: 你的小程序AppSecret file: upload-dir: D:/upload这四个参数是本地启动的生死线。数据库连接串里的 serverTimezone 建议直接写成 Asia/Shanghai否则 MySQL 8 会报时区错误useSSL 设 false 能省掉本地 SSL 握手警告allowPublicKeyRetrievaltrue 是 MySQL 8 用 caching_sha2_password 认证时常见的报错解药配上后少踩一个坑。wx.appid 和 wx.secret 先填测试号或你自己小程序的凭证没有真实小程序时登录链路走不通但商家、骑手、后台管理的账号密码登录通常不受影响仍能继续验证核心流程。上传目录按你电脑实际情况改Windows 写 D:/uploadLinux 写 /data/upload目录不存在时后端要能自动创建否则图片上传接口会报错。3.3 启动后端并用接口自测Swagger 验证登录、菜品与下单配置改完先编译打包再以 jar 方式启动避免 IDE 里跑和命令行跑行为不一致。第一次启动建议用命令行日志输出最直观mvn clean package -Dmaven.test.skiptrue java -jar target/waimai.jar启动完成后看日志里有没有 “Started Application in xx seconds”。如果秒退多半是端口被占、数据库连不上、配置项拼写错误顺着堆栈第一行去查。后端起来后常见源码集成了 Swagger访问 http://localhost:8080/swagger-ui.html 能看到接口清单。我建议按顺序测三个接口先用 wx.login 的 code 调登录接口能返回 openid 说明微信配置通再查一次商家菜品列表能返回数据说明数据库连接和表的映射通最后创建一个测试订单能返回订单号说明事务和状态机通。这三个接口等于把系统主干道验了一遍后面追加的细节问题都好定位。3.4 小程序端联调修改 baseUrl、勾选不校验域名、跑通第一个请求后端稳定后用微信开发者工具导入小程序前端工程。几乎每个源码都会有一个配置文件专门存接口地址常见文件名是 config.js 或 app.js里面有个 baseUrl。本地联调时改成// config.js小程序全局配置 module.exports { baseUrl: http://localhost:8080, // 本地联调用 // 手机真机预览时改成局域网IP例如 http://192.168.1.100:8080 version: 1.0.0 }改完后回到开发者工具点击“详情 - 本地设置”勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。这一步不做所有 wx.request 都会报域名不在合法列表。第一个要跑通的请求是登录用户点击登录按钮后发起 wx.login 拿 code再调后端登录接口最后把返回的 token 存起来。这里有个常见的 UI 坑是自定义导航栏页面在刘海屏上内容会被状态栏遮挡处理方式是获取状态栏高度后撑起顶部布局对应热词里“微信小程序顶部导航栏高度”这是每个外卖小程序页面都要处理的适配细节。联调通过一个请求后再逐步验证首页商家列表、菜品详情、加购下单本地主流程就算通了。4. 二开前先摸清三条业务链路下单、商家接单、骑手配送的状态流转“功能强”不是堆页面而是业务链路完整。二开时最容易改坏的就是状态流转你以为只改了一个字段结果商家接单后用户端状态不跳动。所以动手改代码前先把三条核心链路在纸上画清楚。我通常会在代码里搜索订单状态常量定义把所有状态跳转点列出来再决定改动方案。4.1 用户下单链路从购物车到订单支付回调怎么处理才算幂等用户端下单链路通常是加购物车、确认订单、提交订单、支付、支付回调更新状态。订单状态在 Java 代码里一般定义成常量或枚举这是最值得先抄进自己笔记的一段逻辑public class OrderStatus { public static final int UNPAID 0; // 待支付 public static final int WAIT_ACCEPT 1; // 待商家接单 public static final int DELIVERING 2; // 配送中 public static final int FINISHED 3; // 已完成 public static final int CANCELED 4; // 已取消 public static final int REFUNDED 5; // 已退款 }下单接口的核心是一个大事务生成订单主表、写入订单明细、扣减菜品库存、清空购物车。任一步失败整体回滚。这里最值得注意的不是事务本身而是支付回调的幂等。微信支付会多次通知同一个回调地址如果回调里不加判断每收到一次通知就把订单状态从“待支付”改成“待接单”同时再扣一次库存数据就乱了。常见的正确做法是回调先按订单号查当前状态发现已经是待接单或更靠后的状态直接返回成功不再做任何写操作。代码里的逻辑大致是这样// 支付回调伪代码先查状态再更新保证重复通知不产生副作用 Order order orderMapper.selectByOrderNo(orderNo); if (order.getStatus() ! OrderStatus.UNPAID) { return SUCCESS; // 已处理过直接返回成功 } order.setStatus(OrderStatus.WAIT_ACCEPT); orderMapper.updateById(order);下单接口还要防重复提交。用户手快双击“提交订单”可能生成两笔一模一样的订单前后端都要防前端在按钮点击后置 loading 状态并禁用再次点击后端在订单表上对 order_no 建唯一索引或者要求前端调用下单接口时带一个 token后端判断 token 是否用过。这是“前后端对于按钮重复提交校验方法”的标准解法外卖源码里如果没有二开时一定要补上。4.2 商家接单与菜品上下架上下架字段改在哪里接单后订单状态怎么跳商家端最核心的两个操作是菜品上下架和订单接单。菜品上下架是一个简单的字段更新dish 表里的 shelf_status 从 1 改成 0 之后用户端就再也查不到这道菜。注意用户端查询时一定要加过滤条件否则会出现“下架了还能点”的幻觉-- 用户端菜品列表只查上架状态的菜品 SELECT id, name, price, image, stock FROM dish WHERE merchant_id #{merchantId} AND shelf_status 1 ORDER BY category_id;商家接单则是一个典型的状态跃迁订单从 WAIT_ACCEPT(1) 跳成 DELIVERING(2)。这个动作有个隐藏要求就是必须防止两个商家操作员同时接一单。常见的稳妥写法是在更新语句里带上当前状态条件-- 商家接单只有待接单状态才允许更新影响行数为0说明已被其他操作员处理 UPDATE orders SET status 2 WHERE id #{orderId} AND status 1;如果影响行数是 0前端就提示“订单已被处理”。这种“条件更新”的思路贯穿外卖系统所有抢状态的操作比先 SELECT 再 UPDATE 安全得多。商家端的“新订单提醒”一般用轮询或者 WebSocket 做轮询简单但有时效损耗WebSocket 实时性好但部署时要在 Nginx 额外配代理。二开选哪种取决于你的服务器条件本地联调用轮询完全够用。4.3 骑手配送链路抢单、取餐、送达以及并发场景下如何防止“一单多抢”骑手端的痛点永远是抢单抢单的核心是原子性。如果代码写成“先查询配送单判断 rider_id 为空再更新自己的 id”两个骑手同时操作时两个请求都能读到 rider_id 为空最后都更新成功订单却被抢了两次。正确的姿势是把判断和更新合并成一条 UPDATE-- 骑手抢单只有还没人认领的配送单才能抢到 UPDATE delivery SET rider_id #{riderId}, status 1 WHERE order_id #{orderId} AND rider_id IS NULL;执行后判断影响行数等于 1 说明抢单成功等于 0 说明手慢了。这条 SQL 加了 rider_id IS NULL 条件数据库行锁会保证同一时刻只有一个请求能更新成功。取餐和送达是顺次状态推进分别把 delivery.status 改成 2 和 3同时联动订单主表状态。骑手的位置上传一般是定时把经纬度写到 delivery 表的 lat/lng 字段用户端再定时拉取展示。另外骑手端订单列表一般是长列表接口要做分页。常规做法是传 page 和 pageSize结合“微信小程序页面列表加载更多”的交互用户上拉触底时请求下一页接口返回 total 判断是否还有更多数据。分页接口最容易出的问题是前端下拉刷新时页码没有重置导致新数据永远接在旧数据后面二开时要注意在 onPullDownRefresh 里把 page 重置为 1。5. 从本地到线上部署的实战排查服务器部署、域名校验与高频翻车点本地跑通只能算开发完成部署到线上才是真正的考验。这一章我把常规部署路径和五个高频踩坑记录放在一起讲目的一是让你知道按什么顺序上线二是告诉你上线后如果黑匣子报警从哪里下手排查。5.1 云服务器部署的常规路径打 jar 包、装 Java 环境、Nginx 反代与 HTTPS线上环境常见做法是买一台云服务器装好 JDK 和 MySQL把数据库 SQL 导入再把后端 jar 包传上去用 nohup 启动。前端小程序不用部署到服务器而是用微信开发者工具上传代码后在微信公众平台提交审核发布。整套上线步骤可以浓缩成如下命令# 1. 本地打包跳过测试 mvn clean package -Dmaven.test.skiptrue # 2. 上传 jar 包到服务器后用 nohup 后台启动并指定生产环境配置 nohup java -jar waimai.jar --spring.profiles.activeprod app.log 21 # 3. 确认后端进程已监听 8080 端口 netstat -ntlp | grep 8080后端跑起来之后Nginx 承担两个任务一是把 80/443 端口的请求转发到 8080二是给上传的图片做静态文件映射。下面是一份精简但能用的 Nginx 配置server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/yourdomain.pem; ssl_certificate_key /etc/nginx/ssl/yourdomain.key; # 后端接口反代 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 图片上传目录静态映射 location /upload/ { alias /data/upload/; } }配置好后用 https://yourdomain.com/api/dish/list 这种地址在浏览器里测一下能返回 JSON 就说明转发通了。这里有一个前置条件卡住很多人微信小程序的 wx.request 要求域名必须是 HTTPS并且要在微信公众平台“开发设置 - 服务器域名”里把接口域名加入 request 合法域名列表。如果服务器是大陆节点域名还必须完成 ICP 备案没备案的域名在微信里直接请求失败这一条没有任何绕过的捷径。真机调试时微信开发者工具里“详情 - 本地设置”有一个“不校验合法域名”的开关但它只影响工具和调试版小程序正式版上线必须走合法域名。5.2 五个高频踩坑记录微信登录失败、图片 403、状态不更新、时区错乱、抢单重复上线之后遇到的问题很少是“代码不会写”更多是环境和配置的协同问题。我把这些年处理过的相似场景整理成踩坑记录每一条按现象、原因、解决三步写。坑一微信登录失败接口返回 invalid code 或 40001。现象真机上点登录转圈后报错后端日志出现 “invalid code, rid: xxx”。原因最常见的有两个一是公众平台上的 AppSecret 和代码里配置不一致二是 wx.login 拿到的 code 只能用一次而且有过期时间如果你在前端把 code 打印出来手动测试第二次用必然失效。解决核对 application.yml 里的 appid 和 secret确认后清理后端缓存重启如果是服务器环境再去微信公众平台把服务器出口 IP 加入 IP 白名单否则后端调用微信接口会被拒。这个坑的隐蔽点在于本地用同一个 appid 能登录上服务器就失败十次里有九次是白名单问题。坑二商家上传的菜品图片在小程序里显示一片空白或 403。现象管理后台图片上传成功后台能看到图小程序里加载不出来控制台报 403 或 “Failed to load resource”。原因图片 URL 指向了不带协议标识的外链或者跨域防盗链地址小程序 image 组件对这类地址在真机上限制很多。解决把图片上传功能改到本地服务器的 upload 目录由 Nginx 映射出可访问的 HTTPS 地址再把数据库里 image 字段改成完整 URL。外链图床省事但不可控一旦对方加了防盗链你的菜单图就全挂这也是“系统稳定”四个字里最容易注水的部分。坑三用户支付成功后商家端看不到新订单订单状态停在待支付。现象用户端显示支付成功商家端列表刷新后还是空的数据库里 status 仍是 0。原因支付回调地址没配或者配错微信支付服务器根本调不到你的后端或者回调接口里改了订单状态但没有提交事务异常被吞掉后日志里只有一条让人看不懂的报错。解决在支付下单参数里把 notify_url 写成 https://你的域名/api/pay/notify确认这个地址在浏览器里能直接访问回调处理里先查单、再改状态、最后返回字符串 “SUCCESS”。如果你用的是没有申请微信支付商户号的环境源码一般会留一个模拟支付开关开启后支付接口直接跳过真实回调把订单置为待接单联调和演示阶段很有用。坑四数据库时间比本地时间少了 8 小时订单创建时间对不上。现象服务器上查订单 create_time 是早上 8 点实际本地时间是下午 4 点。原因MySQL 连接串没加 serverTimezone服务器系统时区又是 UTC。解决在 jdbc 连接串里固定加 serverTimezoneAsia/Shanghai并在启动 jar 时加上 JVM 时区参数nohup java -Duser.timezoneAsia/Shanghai -jar waimai.jar app.log 21 时区问题不解决订单统计、配送时长、对账全都会跟着错而且它不会报错属于最磨人的“隐形错误”。改完时区记得重启后端并观察新写入数据的时间旧数据不要手动批量改容易把跨时段数据搞乱。坑五两个骑手同时抢同一单订单被重复认领配送表出现两条记录。现象用户下单后两个骑手几乎同时点抢单后端都返回成功配送表里同一 order_id 出现两条 rider_id 不同的记录。原因代码用了“先查询后更新”的非原子写法。解决把抢单 SQL 改成带 rider_id IS NULL 条件的 UPDATE并按影响行数判断是否成功。如果你在源码里看到类似的抢单逻辑是 SELECT 加 UPDATE 两步别犹豫改掉。这个场景就是“前后端对于按钮重复提交校验方法”在业务层的真实投影前端按钮可以防手滑但后端接口必须自己做状态保护否则并发一上来就穿帮。6. 交付前最后的验证用一份检查清单把“能跑”变成“敢交付”代码改完、部署上线别急着把源码压缩包发出去。我习惯在交付前把下面这份清单从头到尾走一遍重点不是“功能存在”而是“业务闭环能通”。很多源码拿到手能启动但商家端看不到新订单、骑手抢不了单、后台添加的账号登不上这种半成品才是真正的大坑。验证模块验证点通过标准用户端从商家列表到下单支付全流程用户下单后再次进入能看到该订单状态为待接单商家端新订单提醒与接单操作用户下单后商家端能查到新单接单后订单变为配送中骑手端抢单、取餐、送达全链路骑手能抢到一个未被认领的订单其他骑手再抢显示失败管理后台添加商家、添加骑手用新添加的账号能登录对应端并能操作真实业务数据数据一致性订单状态前后端一致数据库 orders.status 与小程序显示的状态完全一致并发安全同一订单双端同时操作两个请求同时抢单只有一个成功备份恢复数据库备份与恢复备份文件能导入到一个全新库业务数据完整我会额外做一件事把服务器 IP、数据库账号密码、小程序 AppID、Nginx 配置路径整理成一份部署文档放进源码包里。密码不写明文至少写清楚“去哪个文件改”。然后我会检查代码里有没有残留本机地址、测试号 AppID、以及前端写死的 localhost——这些是我自己翻过车的点曾因为 code 里留了一个测试密钥导致上线后被别人刷接口从那时候起我交付前都会全局搜索 appsecret、localhost 这类关键词。跑完清单、改完隐患我才会把源码和数据库脚本打成一个压缩包交出去。这个习惯帮我省掉了大量交付后的售后问题也希望帮到你。本文还有配套的精品资源点击获取 Java微信外卖小程序源码二开与部署实战：从架构拆解到并发避坑
简介完整版微信外卖小程序系统源码与数据库打包于一个zip压缩包内面向需要搭建或二次开发外卖平台的开发者、商家及技术学习者。系统基于Java语言开发集商家管理、骑手调度、用户下单、订单跟踪等核心模块于一体前后端完整并支持微信支付等常见接口适用于餐饮、商超、堂食等场景。压缩包共包含2825个文件以日志文件、FastReport报表模板fr3、PDF文档及动态链接库为主日志可供运行排查fr3报表模板方便订单统计展示另有少量配置和图片资源大小约27.61MB便于本地部署与代码阅读。附带数据库设计涵盖用户、商家、商品、订单、骑手等多张数据表通过外键关联保障数据一致性整体目录结构清晰便于按模块对照开发。目前已有908人学习下载适合具备一定Java基础的中高级开发者在真实业务中参考复用。1. 一套 Java 写的微信外卖小程序源码能直接接手当二开基座吗先说明一点标题里的 JAVE 是 Java 的笔误这类外卖源码的实际技术栈几乎都是 Java 系后端用 Spring Boot 提供接口MySQL 存全部业务数据微信小程序承担用户端再配上能登录的管理后台去添加商家、骑手账号。“前后端都有”这几个字才是这套源码最值钱的地方——你拿到手不是一堆碎片而是一条能跑通的业务闭环用户能看菜下单商家能接单上架骑手能抢单配送管理员能在后台维护人和货。它适合三类人有 Java 基础想二开做校园外卖、社区配送的开发者需要完整前后端工程写毕业设计的学生以及想用最低成本快速验证外卖小程序商业模型但不想从零搭一个月的创业者。下面我从架构拆解讲到部署避坑最后给一份能直接抄的交付前验证清单。2. 拆开源码看架构前后端分离、四端工程与核心表设计拿到源码第一件事不是急着启动而是先把目录结构看清楚。常见做法是后端打成一个 Spring Boot 工程前端按“端”拆分目录或拆成多个小程序工程管理后台单独用浏览器访问。先把工程边界摸清后面改代码才不至于一动手就迷路。2.1 前后端分离到底分了哪些“端”用户端、商家端、骑手端与管理后台这套系统的“功能强”主要体现在四个角色各有一套入口而不是登录进去切来切去。多数源码会把前端拆成这几个部分端常见技术栈核心职责与后端的交互方式用户端小程序原生微信小程序或 uni-app浏览商家、加购、下单、支付、确认收货wx.request 调后端 REST 接口商家端小程序原生微信小程序菜品上下架、订单提醒、接单/拒单轮询或 WebSocket 接收新订单通知骑手端小程序原生微信小程序抢单、取餐、送达、上传位置调用配送相关接口管理后台Vue / Element UI 或类似前端框架添加商家、添加骑手、审核、数据统计axios 调后端管理接口为什么要前后端分离而不是做成一个大网页因为外卖场景里四个角色对界面和操作路径的要求完全不一样。用户在手机上追求下单快商家需要同时看到多个新订单并快速处理骑手要的是地图和单子列表管理员则要坐在电脑前维护数据。四个端独立演进也方便你只二改其中一部分。2.2 数据库怎么支撑一次完整的外卖下单商户、菜品、订单、配送的六张核心表数据库是这套源码的骨架我一般拿到源码会先建一个空库把 SQL 导进去然后用可视化工具把表关系画出来看。常见核心表大致是这个结构下面的建表语句做了精简但字段设计思路和完整源码基本一致-- 用户表存微信用户、管理员、商家、骑手共用的基础账号信息 CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) DEFAULT NULL COMMENT 微信openid, phone varchar(20) DEFAULT NULL COMMENT 手机号, username varchar(50) DEFAULT NULL COMMENT 后台登录账号, password varchar(100) DEFAULT NULL COMMENT 后台登录密码, role tinyint(4) DEFAULT 0 COMMENT 0用户 1商家 2骑手 3管理员, status tinyint(4) DEFAULT 1 COMMENT 1正常 0禁用, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 商家表一条记录对应一个入驻外卖平台的店铺 CREATE TABLE merchant ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) DEFAULT NULL COMMENT 关联user表, name varchar(100) DEFAULT NULL COMMENT 店铺名称, notice varchar(255) DEFAULT NULL COMMENT 公告, delivery_fee decimal(10,2) DEFAULT 0.00 COMMENT 配送费, status tinyint(4) DEFAULT 1 COMMENT 1营业 0打烊, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 菜品表归属某个商家上下架状态直接决定用户在端上能不能看到 CREATE TABLE dish ( id bigint(20) NOT NULL AUTO_INCREMENT, merchant_id bigint(20) DEFAULT NULL, category_id bigint(20) DEFAULT NULL COMMENT 分类id, name varchar(100) DEFAULT NULL, price decimal(10,2) DEFAULT NULL, image varchar(255) DEFAULT NULL COMMENT 图片URL, shelf_status tinyint(4) DEFAULT 1 COMMENT 1上架 0下架, stock int(11) DEFAULT 0 COMMENT 库存, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单主表一次下单生成一条记录状态机贯穿整个配送流程 CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) DEFAULT NULL COMMENT 订单号, user_id bigint(20) DEFAULT NULL, merchant_id bigint(20) DEFAULT NULL, total_amount decimal(10,2) DEFAULT NULL, status tinyint(4) DEFAULT 0 COMMENT 0待支付 1待接单 2配送中 3已完成 4已取消 5退款, address varchar(255) DEFAULT NULL, remark varchar(255) DEFAULT NULL, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单明细表一个订单对应多条菜品记录 CREATE TABLE order_detail ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) DEFAULT NULL, dish_id bigint(20) DEFAULT NULL, dish_name varchar(100) DEFAULT NULL, price decimal(10,2) DEFAULT NULL, quantity int(11) DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 配送表订单被骑手认领后配送状态和位置信息在这里更新 CREATE TABLE delivery ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) DEFAULT NULL, rider_id bigint(20) DEFAULT NULL COMMENT 骑手user_id, status tinyint(4) DEFAULT 0 COMMENT 0待抢 1已接单 2取餐 3送达, lat decimal(10,6) DEFAULT NULL COMMENT 骑手纬度, lng decimal(10,6) DEFAULT NULL COMMENT 骑手经度, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这套表的精髓在于“资金、货、人”分开存。订单主表只管状态和金额明细表管具体买了什么配送表管履约过程商家和骑手通过 user_id 关联到 user 表而不是各自维护一套登录体系。做数据库增删改查时思路就清晰下单一笔事务要同时写 orders、order_detail、dish 库存和 cart 购物车任何一步失败整个事务回滚线上才不会出现“用户付了钱商家看不到单”的诡异问题。2.3 权限模型一个用户如何变成商家或骑手管理后台又是怎么“添加”出来的标题特别强调“可添加商家、骑手”这里的关键不是写一行 INSERT而是后台添加完之后新商家能立刻用自己的账号登录并管理店铺。常见的设计是 user 表统一存账号role 字段区分身份再用业务扩展表补齐信息。管理后台添加商家的本质是两步先插 user 表生成一个账号再插 merchant 表把账号和店铺绑定。-- 查询某微信用户身份时通常要把基础账号和业务身份连查 SELECT u.id, u.role, m.id AS merchant_id, m.name AS merchant_name FROM user u LEFT JOIN merchant m ON m.user_id u.id WHERE u.openid #{openid};这个连查在登录接口里几乎是标配。用户进入小程序先 wx.login 换 openid后端拿着 openid 查一次用户返回角色如果 role 是商家前端跳商家工作台如果 role 是骑手跳骑手接单页如果没有记录就默认走普通用户流程。管理后台“添加骑手”同理插一条 user 记录再插骑手扩展表初始密码常见的做法是后台生成一个随机密码第一次登录后要求修改避免账号裸奔。权限模型最怕的坑是角色和业务数据脱节删了 user 表记录却忘记删 merchant 或 rider 扩展表会导致登录后无法加载店铺最后只能手动清垃圾数据。3. 本地跑通最小系统导入数据库、改配置、启动后端、小程序联调“系统稳定”这种描述只有在你亲眼看到它跑起来之后才有意义。本地跑通是整个二开过程的地基我把流程压成四步装环境、导 SQL 改配置、启动后端、小程序联调。每一步失败都有固定解法别硬闯。3.1 环境准备JDK、Maven、MySQL 与微信开发者工具的最小版本组合常见做法是 JDK 1.8 或 11、Maven 3.6 以上、MySQL 5.7 或 8.0、微信开发者工具最新稳定版。如果源码用了 MyBatis-Plus 和 LombokIDEA 里还要装 Lombok 插件否则编译直接报“找不到 getter/setter”。这里先检查一个最容易翻车的点JDK 版本太高而源码是基于 JDK 8 写的Maven 编译可能报 “无效的发行版本”。不用急着升 JDK先看 pom.xml 里 java.version 写的是多少保持一致再跑。# 检查本机环境确认三个基础工具就位 java -version mvn -v mysql --version没有 JDK 或 Maven 时去对应官网下载安装包配置环境变量即可。MySQL 安装完记得确认服务已启动Windows 下常见问题是端口被占用或 root 密码复杂度不符合要求这些和源码本身无关但会浪费你大量排查时间。3.2 导入 SQL 与修改 application.yml四个不改就启动失败的参数用可视化工具新建一个空库字符集选 utf8mb4然后把源码附带的 .sql 文件整体导入。导入成功后重点检查表数量是否和源码自带数据库说明一致如果少了几张表多半是 SQL 文件执行到一半报错中断需要按错误提示修正后重新导入。之后打开后端的 application.yml重点改这几项server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/waimai?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver wx: appid: 你的小程序AppID secret: 你的小程序AppSecret file: upload-dir: D:/upload这四个参数是本地启动的生死线。数据库连接串里的 serverTimezone 建议直接写成 Asia/Shanghai否则 MySQL 8 会报时区错误useSSL 设 false 能省掉本地 SSL 握手警告allowPublicKeyRetrievaltrue 是 MySQL 8 用 caching_sha2_password 认证时常见的报错解药配上后少踩一个坑。wx.appid 和 wx.secret 先填测试号或你自己小程序的凭证没有真实小程序时登录链路走不通但商家、骑手、后台管理的账号密码登录通常不受影响仍能继续验证核心流程。上传目录按你电脑实际情况改Windows 写 D:/uploadLinux 写 /data/upload目录不存在时后端要能自动创建否则图片上传接口会报错。3.3 启动后端并用接口自测Swagger 验证登录、菜品与下单配置改完先编译打包再以 jar 方式启动避免 IDE 里跑和命令行跑行为不一致。第一次启动建议用命令行日志输出最直观mvn clean package -Dmaven.test.skiptrue java -jar target/waimai.jar启动完成后看日志里有没有 “Started Application in xx seconds”。如果秒退多半是端口被占、数据库连不上、配置项拼写错误顺着堆栈第一行去查。后端起来后常见源码集成了 Swagger访问 http://localhost:8080/swagger-ui.html 能看到接口清单。我建议按顺序测三个接口先用 wx.login 的 code 调登录接口能返回 openid 说明微信配置通再查一次商家菜品列表能返回数据说明数据库连接和表的映射通最后创建一个测试订单能返回订单号说明事务和状态机通。这三个接口等于把系统主干道验了一遍后面追加的细节问题都好定位。3.4 小程序端联调修改 baseUrl、勾选不校验域名、跑通第一个请求后端稳定后用微信开发者工具导入小程序前端工程。几乎每个源码都会有一个配置文件专门存接口地址常见文件名是 config.js 或 app.js里面有个 baseUrl。本地联调时改成// config.js小程序全局配置 module.exports { baseUrl: http://localhost:8080, // 本地联调用 // 手机真机预览时改成局域网IP例如 http://192.168.1.100:8080 version: 1.0.0 }改完后回到开发者工具点击“详情 - 本地设置”勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。这一步不做所有 wx.request 都会报域名不在合法列表。第一个要跑通的请求是登录用户点击登录按钮后发起 wx.login 拿 code再调后端登录接口最后把返回的 token 存起来。这里有个常见的 UI 坑是自定义导航栏页面在刘海屏上内容会被状态栏遮挡处理方式是获取状态栏高度后撑起顶部布局对应热词里“微信小程序顶部导航栏高度”这是每个外卖小程序页面都要处理的适配细节。联调通过一个请求后再逐步验证首页商家列表、菜品详情、加购下单本地主流程就算通了。4. 二开前先摸清三条业务链路下单、商家接单、骑手配送的状态流转“功能强”不是堆页面而是业务链路完整。二开时最容易改坏的就是状态流转你以为只改了一个字段结果商家接单后用户端状态不跳动。所以动手改代码前先把三条核心链路在纸上画清楚。我通常会在代码里搜索订单状态常量定义把所有状态跳转点列出来再决定改动方案。4.1 用户下单链路从购物车到订单支付回调怎么处理才算幂等用户端下单链路通常是加购物车、确认订单、提交订单、支付、支付回调更新状态。订单状态在 Java 代码里一般定义成常量或枚举这是最值得先抄进自己笔记的一段逻辑public class OrderStatus { public static final int UNPAID 0; // 待支付 public static final int WAIT_ACCEPT 1; // 待商家接单 public static final int DELIVERING 2; // 配送中 public static final int FINISHED 3; // 已完成 public static final int CANCELED 4; // 已取消 public static final int REFUNDED 5; // 已退款 }下单接口的核心是一个大事务生成订单主表、写入订单明细、扣减菜品库存、清空购物车。任一步失败整体回滚。这里最值得注意的不是事务本身而是支付回调的幂等。微信支付会多次通知同一个回调地址如果回调里不加判断每收到一次通知就把订单状态从“待支付”改成“待接单”同时再扣一次库存数据就乱了。常见的正确做法是回调先按订单号查当前状态发现已经是待接单或更靠后的状态直接返回成功不再做任何写操作。代码里的逻辑大致是这样// 支付回调伪代码先查状态再更新保证重复通知不产生副作用 Order order orderMapper.selectByOrderNo(orderNo); if (order.getStatus() ! OrderStatus.UNPAID) { return SUCCESS; // 已处理过直接返回成功 } order.setStatus(OrderStatus.WAIT_ACCEPT); orderMapper.updateById(order);下单接口还要防重复提交。用户手快双击“提交订单”可能生成两笔一模一样的订单前后端都要防前端在按钮点击后置 loading 状态并禁用再次点击后端在订单表上对 order_no 建唯一索引或者要求前端调用下单接口时带一个 token后端判断 token 是否用过。这是“前后端对于按钮重复提交校验方法”的标准解法外卖源码里如果没有二开时一定要补上。4.2 商家接单与菜品上下架上下架字段改在哪里接单后订单状态怎么跳商家端最核心的两个操作是菜品上下架和订单接单。菜品上下架是一个简单的字段更新dish 表里的 shelf_status 从 1 改成 0 之后用户端就再也查不到这道菜。注意用户端查询时一定要加过滤条件否则会出现“下架了还能点”的幻觉-- 用户端菜品列表只查上架状态的菜品 SELECT id, name, price, image, stock FROM dish WHERE merchant_id #{merchantId} AND shelf_status 1 ORDER BY category_id;商家接单则是一个典型的状态跃迁订单从 WAIT_ACCEPT(1) 跳成 DELIVERING(2)。这个动作有个隐藏要求就是必须防止两个商家操作员同时接一单。常见的稳妥写法是在更新语句里带上当前状态条件-- 商家接单只有待接单状态才允许更新影响行数为0说明已被其他操作员处理 UPDATE orders SET status 2 WHERE id #{orderId} AND status 1;如果影响行数是 0前端就提示“订单已被处理”。这种“条件更新”的思路贯穿外卖系统所有抢状态的操作比先 SELECT 再 UPDATE 安全得多。商家端的“新订单提醒”一般用轮询或者 WebSocket 做轮询简单但有时效损耗WebSocket 实时性好但部署时要在 Nginx 额外配代理。二开选哪种取决于你的服务器条件本地联调用轮询完全够用。4.3 骑手配送链路抢单、取餐、送达以及并发场景下如何防止“一单多抢”骑手端的痛点永远是抢单抢单的核心是原子性。如果代码写成“先查询配送单判断 rider_id 为空再更新自己的 id”两个骑手同时操作时两个请求都能读到 rider_id 为空最后都更新成功订单却被抢了两次。正确的姿势是把判断和更新合并成一条 UPDATE-- 骑手抢单只有还没人认领的配送单才能抢到 UPDATE delivery SET rider_id #{riderId}, status 1 WHERE order_id #{orderId} AND rider_id IS NULL;执行后判断影响行数等于 1 说明抢单成功等于 0 说明手慢了。这条 SQL 加了 rider_id IS NULL 条件数据库行锁会保证同一时刻只有一个请求能更新成功。取餐和送达是顺次状态推进分别把 delivery.status 改成 2 和 3同时联动订单主表状态。骑手的位置上传一般是定时把经纬度写到 delivery 表的 lat/lng 字段用户端再定时拉取展示。另外骑手端订单列表一般是长列表接口要做分页。常规做法是传 page 和 pageSize结合“微信小程序页面列表加载更多”的交互用户上拉触底时请求下一页接口返回 total 判断是否还有更多数据。分页接口最容易出的问题是前端下拉刷新时页码没有重置导致新数据永远接在旧数据后面二开时要注意在 onPullDownRefresh 里把 page 重置为 1。5. 从本地到线上部署的实战排查服务器部署、域名校验与高频翻车点本地跑通只能算开发完成部署到线上才是真正的考验。这一章我把常规部署路径和五个高频踩坑记录放在一起讲目的一是让你知道按什么顺序上线二是告诉你上线后如果黑匣子报警从哪里下手排查。5.1 云服务器部署的常规路径打 jar 包、装 Java 环境、Nginx 反代与 HTTPS线上环境常见做法是买一台云服务器装好 JDK 和 MySQL把数据库 SQL 导入再把后端 jar 包传上去用 nohup 启动。前端小程序不用部署到服务器而是用微信开发者工具上传代码后在微信公众平台提交审核发布。整套上线步骤可以浓缩成如下命令# 1. 本地打包跳过测试 mvn clean package -Dmaven.test.skiptrue # 2. 上传 jar 包到服务器后用 nohup 后台启动并指定生产环境配置 nohup java -jar waimai.jar --spring.profiles.activeprod app.log 21 # 3. 确认后端进程已监听 8080 端口 netstat -ntlp | grep 8080后端跑起来之后Nginx 承担两个任务一是把 80/443 端口的请求转发到 8080二是给上传的图片做静态文件映射。下面是一份精简但能用的 Nginx 配置server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/yourdomain.pem; ssl_certificate_key /etc/nginx/ssl/yourdomain.key; # 后端接口反代 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 图片上传目录静态映射 location /upload/ { alias /data/upload/; } }配置好后用 https://yourdomain.com/api/dish/list 这种地址在浏览器里测一下能返回 JSON 就说明转发通了。这里有一个前置条件卡住很多人微信小程序的 wx.request 要求域名必须是 HTTPS并且要在微信公众平台“开发设置 - 服务器域名”里把接口域名加入 request 合法域名列表。如果服务器是大陆节点域名还必须完成 ICP 备案没备案的域名在微信里直接请求失败这一条没有任何绕过的捷径。真机调试时微信开发者工具里“详情 - 本地设置”有一个“不校验合法域名”的开关但它只影响工具和调试版小程序正式版上线必须走合法域名。5.2 五个高频踩坑记录微信登录失败、图片 403、状态不更新、时区错乱、抢单重复上线之后遇到的问题很少是“代码不会写”更多是环境和配置的协同问题。我把这些年处理过的相似场景整理成踩坑记录每一条按现象、原因、解决三步写。坑一微信登录失败接口返回 invalid code 或 40001。现象真机上点登录转圈后报错后端日志出现 “invalid code, rid: xxx”。原因最常见的有两个一是公众平台上的 AppSecret 和代码里配置不一致二是 wx.login 拿到的 code 只能用一次而且有过期时间如果你在前端把 code 打印出来手动测试第二次用必然失效。解决核对 application.yml 里的 appid 和 secret确认后清理后端缓存重启如果是服务器环境再去微信公众平台把服务器出口 IP 加入 IP 白名单否则后端调用微信接口会被拒。这个坑的隐蔽点在于本地用同一个 appid 能登录上服务器就失败十次里有九次是白名单问题。坑二商家上传的菜品图片在小程序里显示一片空白或 403。现象管理后台图片上传成功后台能看到图小程序里加载不出来控制台报 403 或 “Failed to load resource”。原因图片 URL 指向了不带协议标识的外链或者跨域防盗链地址小程序 image 组件对这类地址在真机上限制很多。解决把图片上传功能改到本地服务器的 upload 目录由 Nginx 映射出可访问的 HTTPS 地址再把数据库里 image 字段改成完整 URL。外链图床省事但不可控一旦对方加了防盗链你的菜单图就全挂这也是“系统稳定”四个字里最容易注水的部分。坑三用户支付成功后商家端看不到新订单订单状态停在待支付。现象用户端显示支付成功商家端列表刷新后还是空的数据库里 status 仍是 0。原因支付回调地址没配或者配错微信支付服务器根本调不到你的后端或者回调接口里改了订单状态但没有提交事务异常被吞掉后日志里只有一条让人看不懂的报错。解决在支付下单参数里把 notify_url 写成 https://你的域名/api/pay/notify确认这个地址在浏览器里能直接访问回调处理里先查单、再改状态、最后返回字符串 “SUCCESS”。如果你用的是没有申请微信支付商户号的环境源码一般会留一个模拟支付开关开启后支付接口直接跳过真实回调把订单置为待接单联调和演示阶段很有用。坑四数据库时间比本地时间少了 8 小时订单创建时间对不上。现象服务器上查订单 create_time 是早上 8 点实际本地时间是下午 4 点。原因MySQL 连接串没加 serverTimezone服务器系统时区又是 UTC。解决在 jdbc 连接串里固定加 serverTimezoneAsia/Shanghai并在启动 jar 时加上 JVM 时区参数nohup java -Duser.timezoneAsia/Shanghai -jar waimai.jar app.log 21 时区问题不解决订单统计、配送时长、对账全都会跟着错而且它不会报错属于最磨人的“隐形错误”。改完时区记得重启后端并观察新写入数据的时间旧数据不要手动批量改容易把跨时段数据搞乱。坑五两个骑手同时抢同一单订单被重复认领配送表出现两条记录。现象用户下单后两个骑手几乎同时点抢单后端都返回成功配送表里同一 order_id 出现两条 rider_id 不同的记录。原因代码用了“先查询后更新”的非原子写法。解决把抢单 SQL 改成带 rider_id IS NULL 条件的 UPDATE并按影响行数判断是否成功。如果你在源码里看到类似的抢单逻辑是 SELECT 加 UPDATE 两步别犹豫改掉。这个场景就是“前后端对于按钮重复提交校验方法”在业务层的真实投影前端按钮可以防手滑但后端接口必须自己做状态保护否则并发一上来就穿帮。6. 交付前最后的验证用一份检查清单把“能跑”变成“敢交付”代码改完、部署上线别急着把源码压缩包发出去。我习惯在交付前把下面这份清单从头到尾走一遍重点不是“功能存在”而是“业务闭环能通”。很多源码拿到手能启动但商家端看不到新订单、骑手抢不了单、后台添加的账号登不上这种半成品才是真正的大坑。验证模块验证点通过标准用户端从商家列表到下单支付全流程用户下单后再次进入能看到该订单状态为待接单商家端新订单提醒与接单操作用户下单后商家端能查到新单接单后订单变为配送中骑手端抢单、取餐、送达全链路骑手能抢到一个未被认领的订单其他骑手再抢显示失败管理后台添加商家、添加骑手用新添加的账号能登录对应端并能操作真实业务数据数据一致性订单状态前后端一致数据库 orders.status 与小程序显示的状态完全一致并发安全同一订单双端同时操作两个请求同时抢单只有一个成功备份恢复数据库备份与恢复备份文件能导入到一个全新库业务数据完整我会额外做一件事把服务器 IP、数据库账号密码、小程序 AppID、Nginx 配置路径整理成一份部署文档放进源码包里。密码不写明文至少写清楚“去哪个文件改”。然后我会检查代码里有没有残留本机地址、测试号 AppID、以及前端写死的 localhost——这些是我自己翻过车的点曾因为 code 里留了一个测试密钥导致上线后被别人刷接口从那时候起我交付前都会全局搜索 appsecret、localhost 这类关键词。跑完清单、改完隐患我才会把源码和数据库脚本打成一个压缩包交出去。这个习惯帮我省掉了大量交付后的售后问题也希望帮到你。本文还有配套的精品资源点击获取