点餐小程序完整源码部署实操：从数据库初始化到前后端联调避坑指南

简介这是一份面向微信小程序开发者的完整点餐项目源码内置前端用户界面、后台服务与数据库脚本适合餐饮行业小程序实战或前后端联调学习的中初级开发者。压缩包共84个文件约1.25MB以js逻辑、json配置、wxml/wxss页面样式、png/jpeg图片素材、sql数据库脚本及pem/p12支付证书为主目录组织清晰。源码实现菜单展示、购物车点餐、订单提交、微信支付和订单状态管理后台覆盖菜品、订单、用户管理数据库设计包含菜品表、订单表、订单详情表、用户表、支付表可完整体现小程序、服务端与数据库之间的协作流程。已有4700人学习下载通读并改造代码能帮助理解小程序API调用、HTTPS数据交互、微信支付接入及表结构设计为独立开发餐饮点餐小程序提供可落地的工程参考。1. 完整的点餐小程序源码完整在哪前后端加库缺一角就跑不起来拿到一份标注“完整的点餐小程序源码带后台和数据库”的压缩包时很多人默认解压、导入微信开发者工具就能看到菜品列表。实际不然这类源码通常由小程序前端、后台管理端和数据库脚本三部分组成前端要连后台接口后台要连数据库缺一个环节就只能看到静态页面或直接白屏。我做过几个外卖与堂食点餐项目今天这篇笔记就是基于这类完整源码的落地经验适合刚拿到代码的开发者、做毕设的学生以及准备给小型餐厅快速搭一套点单系统的人。你会看到这套源码从环境准备到数据初始化的全过程也会知道哪些地方最容易翻车。这套系统要真正用起来第一步不是看代码而是先看它的部署文档和数据库脚本。2. 先看清这套源码的组成小程序端、管理后台和数据库三件套拿到手先别急着跑先按目录结构把项目认全。一般点餐小程序的完整源码包含 client / admin / server / sql 这样几个目录或者小程序端是单独一个分包。先分清楚职责后续配置才不迷路。最常见的目录是 miniprogram小程序前端、manage后台管理页面、server接口服务、databaseSQL 脚本。不同源码命名不一样但角色不会变。2.1 小程序端页面、请求封装和登录态常见的小程序端基于原生框架目录里会有 pages / components / utils / api。核心页面一般包括首页点餐、菜品分类、购物车、订单列表、个人中心。我要说的第一个技术点不是页面长什么样而是 request 封装。几乎所有页面都通过一个统一方法发请求这样后台地址改一处全局生效。典型封装如下// utils/request.js const BASE_URL http://localhost:8080/api // 后台接口前缀 function request({ url, method GET, data {} }) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success: res { if (res.data.code 200) { resolve(res.data) } else if (res.data.code 401) { wx.navigateTo({ url: /pages/login/login }) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res.data) } }, fail: err reject(err) }) }) } module.exports { request, BASE_URL }这段代码的作用是统一拼接后台接口地址并把用户 token 自动放到请求头里。参数说明BASE_URL 在本地开发时用http://localhost:8080/api真机预览时不能再用 localhost要改成电脑局域网 IP 或已备案的 HTTPS 域名。wx.getStorageSync(token)从本地缓存读取登录凭证所以登录成功之后务必把 token 写进 Storage。如果源码里的请求封装没有做 401 跳转建议加上因为带后台的源码一旦登录过期前端会不断报错而不是引导用户重新登录。这里还要注意小程序端有多个页面都要展示菜品图片所以源码里通常会有一个utils/config.js单独存“图片域名”和“接口域名”。修改配置时这两个域名要一起改否则会出现“数据能拉取但图片裂掉”的怪问题。登录态建立这块代码也很固定wx.login({ success: res { wx.request({ url: BASE_URL /user/login, method: POST, data: { code: res.code }, success: resp { wx.setStorageSync(token, resp.data.token) wx.setStorageSync(userInfo, resp.data.userInfo) } }) } })小程序端用wx.login拿到临时 code发给后台后台再用 code 换 openid 生成自己的登录态。真正要改的是后台那个/user/login接口不是小程序这段。很多源码把这部分写得很绕其实看懂数据流就清楚了临时 code 是一次性的后台换 openid 时如果报错多半是后台的 appid 和 secret 还没配。2.2 管理后台常见技术栈与功能模块后台管理系统最常见的组合是 Vue2/3 Element UI或者干脆是 PHP 写的一体化后台。最近很多新写的点餐源码用 Vue3 后台管理系统界面更现代但结构复杂一点多了一层 Node 的构建步骤。点餐项目的后台重点在三块菜品分类与菜品管理、桌台/门店信息、订单列表与状态修改。后台和数据库的距离最近操作的都是 SQL。比如后台菜品列表要做“上架/下架”本质就是改数据库一个字段。我拿到后台代码后会先看路由表理清页面和权限的关系。很多源码的后台带角色权限能分清管理员和普通员工。启动后台后先用默认账号登录第一件事是打开用户管理给当前账号分配角色不然菜单能显示但点保存、删除的时候会提示无权限。这是新手最容易误以为“源码有问题”的地方。后台模块里菜品管理通常包含增删改查。增删改查表面简单但点餐系统有一个特别之处菜品数据要被小程序端读取后台修改后小程序端需要立刻看到效果。所以后台修改菜品时不要把status字段漏掉下架的商品不能出现在小程序端的菜单里。代码里如果用了 Redis 缓存菜品列表还要做缓存清理否则后台改了价格小程序端永远显示旧价格。2.3 数据库核心表结构与订单状态机数据库是整套源码的灵魂。点餐小程序的数据库最少包含用户表、菜品分类表、菜品表、订单表、订单明细表。表之间关系很简单但订单状态这个字段值得单独说。一般用 int 表示比如状态值含义常见操作0待支付用户提交订单后生成未支付1待接单支付成功后台看到新订单2制作中后厨确认3已配送/待取餐堂食或外送场景4已完成订单闭环5已取消用户或后台取消理解这张表你才能改后台订单状态逻辑。完整源码里通常还有门店设置表和支付配置表支付配置表用来存商户号和密钥这部分在部署时最容易踩坑后面专门说。数据库脚本里一般还会插入一些演示菜品和分类数据方便你第一时间看到效果如果你要正式使用需要把演示数据清掉改造成自己的菜品。提示不要以为 SQL 脚本里建好表就完事。数据库版本、字符集和索引都会影响表现。建议建表后在订单表加上order_no唯一索引避免重复订单尤其是你后续要做订单号幂等时这个索引能兜底。这里补充一个 SQL 查询技巧点餐系统里经常要查“今日订单数”“最热菜品”这类报表查询直接写在后台代码里会很乱。常见做法是在数据库脚本里建视图比如菜品销售统计视图把订单明细表和菜品表 join 起来。源码里如果没有视图你可以在 navicat 里自己建不影响二次开发。3. 把整套源码跑起来本地部署步骤与参数设置本地跑通是后续所有改动的前提。这一章按顺序来每个步骤都值得仔细检查。源码包含后台和数据库所以要先建库再启动后台最后打开小程序。别反着来否则接口连不上你会到处找原因。3.1 准备环境微信开发者工具、后台运行环境、数据库如果后台是 Java Spring Boot需要 JDK 8/11 和 Maven如果是 Node.js需要 Node 12 以上和 npm如果是 PHP需要 Apache/nginx 加 PHP 环境。数据库基本是 MySQL 5.7 或 8.0。建议先用 MySQL 5.7兼容性和坑最少。数据库增删改查是基础源码里封装了通用 JDBC 或 ORM 的先跑通一个查询确认连接没问题。确认环境最直接的命令# 检查 Java、Node 和 MySQL 是否可用的常用命令 java -version node -v mysql --version如果提示找不到命令说明对应环境变量没配好。尤其 Windows 上装完 MySQL 后需要在系统 PATH 里加入 MySQL 的 bin 目录这是很多新手第一次跑源码失败的原因。另建议把微信开发者工具也更新到稳定版新版工具有些接口行为和老版不同比如wx.login的返回老源码不一定兼容。3.2 数据库初始化导入 SQL 脚本与修改连接配置源码里一般会提供db.sql或init.sql。打开这份文件会看到建库、建表、插入初始数据的语句。先建库例如-- 创建数据库注意字符集 CREATE DATABASE IF NOT EXISTS ordering_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE ordering_system; -- 执行数据库脚本 SOURCE /path/to/db.sql;导入完成后下一步是把后台代码里的数据库连接改掉。常见配置文件是application.yml、application.properties或 PHP 的config/database.php。里面几个参数必须对应你的本地环境# application.yml 示例 spring: datasource: url: jdbc:mysql://localhost:3306/ordering_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver参数说明端口 3306 是 MySQL 默认端口如果安装时改成 3307这里要同步改。characterEncodingutf8保证菜品名和备注中的中文不出现乱码。useSSLfalse是本地调试常用的云服务器上如果数据库强制 SSL这里要反过来。serverTimezoneAsia/Shanghai解决了 Java 8 连接 MySQL 时的时区问题这也是老源码经常被忽略的配置。如果在启动日志里看到The server time zone value的报错就是少了这一项。导入成功怎么看在 MySQL 命令行执行show tables;能看到所有表并且菜品分类表里已经有几条初始分类数据说明脚本完整。如果导入时中途报错可能是 SQL 文件里包含了DROP DATABASE语句把现有库删了建议在执行前备份。顺便执行一句SHOW VARIABLES LIKE character_set_database;检查字符集是不是utf8mb4不是的话中文容易变问号。3.3 后台接口与本地联调请求地址、CORS 与 token 验证后台启动成功后会占用一个端口。常见有 8080 或 9090。先确认后台能通过浏览器访问如果你是前后端分离后台通常会先访问登录页。如果是 Swagger 接口文档则访问/swagger-ui.html可以列出所有接口。先测一个登录接口拿到 token再看菜品列表接口。我习惯用 postman 先跑通再到小程序里跑这样能把前后端问题分开。接下来要处理跨域。小程序请求后台不存在浏览器跨域问题但开发时如果用 H5 后台、或网页版调试就需要后端开启 CORS。源码里一般会有跨域配置类核心是这些// CorsConfig.java 的跨域配置关键点 registry.addMapping(/api/**) .allowedOrigins(http://localhost:8081) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true);这段配置说明只允许来自http://localhost:8081的请求跨域访问/api/**路径。如果开发者工具里后台地址是http://localhost:8080而管理后台页面在 8081要把 allowedOrigins 改掉。allowCredentials(true)意味着前端请求要带上 cookie这时allowedOrigins不能写*必须写具体地址。查跨域问题最快的办法是打开浏览器开发者工具的控制台看到CORS policy字样的报错核对 origin 地址。token 验证这一段最常见的问题是登录接口返回后前端只存了 token但没有把 token 放进后续请求。源码的封装如果像我上面那样统一放 header就不会出问题。如果后台接口要求 token 在Authorization: Bearer xxx里你要在封装里把字符串拼接成Bearer token不要只放原始 token。后台返回的数据结构一般约定为{ code, msg, data }你可以在 request 封装里直接判断 code不用每个页面都处理。3.4 小程序端配置appid、合法域名与本地调试最后才动小程序端因为它的配置依赖后台地址已经确定。在微信开发者工具里导入项目目录先做三件事在project.config.json里填自己的 appid如果没有就用测试号测试号不能做登录和支付但能看到页面。在工具右上角“详情-本地设置”勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。在之前的 request.js 中把 BASE_URL 改成http://127.0.0.1:8080/api或局域网 IP。做完这三步编译一次首页能拉到菜品数据说明小程序端到后台链路通了。这里的坑在于开发者工具模拟器里访问http://localhost没问题但手机预览时localhost指向手机自己所以必须用局域网 IP 或域名。真机预览时电脑和手机要连同一个 Wi-Fi然后把后台端口开放给局域网访问比如 Windows 防火墙要允许 8080 端口的入站连接。如果编译后页面空白先看 Console 里的报错。request:fail说明网络层失败检查地址和防火墙statusCode: 404说明接口路径不对401说明登录态没传或已过期。这些问题按状态码去查比瞎猜快得多。4. 二次开发避坑指南登录、支付、图片和订单并发的常见问题这类点餐源码最常见的翻车点集中在这几个模块。每一条都是我在实际部署中遇到过的按“现象-原因-解决”来写方便你对照。4.1 微信小程序登录获取手机号getPhoneNumber 不再返回明文很多点餐源码的登录页写着“微信一键登录获取手机号”但注意2023 年后button open-typegetPhoneNumber获取手机号这种方式已经不能直接拿到完整手机号只能拿到动态令牌需要在后台调用phonenumber.getPhoneNumber接口换取且需要微信认证和非个人主体。源码如果直接用e.detail.phoneNumber来保存用户手机号大概率拿不到。现象点击获取手机号按钮e.detail.phoneNumber为 null或提示“手机号快速验证组件需企业认证”。原因微信调整了手机号快速验证能力个人小程序无法使用且旧接口的逻辑已经失效。解决建议绕开手机号强制绑定。先让用户用微信登录拿 openid生成业务 token手机号作为选填项放在个人中心里通过短信验证码绑定。如果后台接口仍然依赖手机号需要把用户表的主键改成 openid手机号只做普通字段并保留旧字段不删迁移数据后再改主键。后端换取手机号的新接口需要传code代码大致是// 小程序端获取手机号后把 e.detail.code 发给后台 wx.request({ url: BASE_URL /user/bindPhone, method: POST, data: { phoneCode: e.detail.code }, header: { Authorization: token } })后台再用phoneCode调用微信接口换取手机号。如果源码里没有这个接口你就需要自己去微信开放平台申请接口权限并配置 API 密钥。不要尝试在纯前端解密手机号换取必须在后台完成否则会泄露密钥。这里顺便说一句数据库里原有的手机号字段不要急着删先用ALTER TABLE user ADD openid VARCHAR(64)加列数据迁移完成后再决定是否去掉旧字段。4.2 支付回调与订单状态不一致的排查带后台的完整源码一般会预留微信支付接口但许多源码只能走到生成预支付订单回调部分简化了。于是用户付完钱订单仍是“待支付”。现象微信支付成功后台订单状态不更新用户反复看到待支付订单。原因支付回调地址没有配置或回调验签代码写错也有可能是回调地址用了http://localhost导致微信服务器无法访问。解决先打开后台日志看是否有微信服务器发来的 POST 请求。如果没有就检查后台设置里的回调 URL 是不是外网可访问的 HTTPS 地址。开发阶段可以用内网穿透工具把本地后台映射到公网但正式环境必须用备案域名不能用 IP。这里的关键是验签逻辑支付成功回调的数据需要验证签名签名密钥与商户号要一一对应。源码里如果用的是老版本pay.unifiedorder接口建议直接按微信支付 APIv3 重写回调逻辑兼容新支付证书。另外收到回调后要返回{code:SUCCESS}给微信否则微信会重复通知多次订单可能被重复更新。排查时直接在后台日志目录里过滤“notify”关键字grep -i notify /var/log/ordering/backend.log | tail -50如果完全没有任何记录先查回调地址外网通不通。如果记录里有验签失败重点看证书序列号和 APIv3 密钥是否填反了。这一步能省下很多和支付平台客服来回沟通的时间。4.3 图片上传后路径失效问题点餐菜品必须传图片但源码里上传功能的细节非常多。这问题在后台管理系统里极常见而且很隐蔽。现象后台添加菜品时上传了图片小程序端菜品图片不显示或者显示旧的缓存图。原因常见是上传接口保存图片到磁盘相对路径后台重启后文件被清空或上传地址用了绝对路径但小程序端访问时 BASE_URL 不一致也有可能是 Nginx 没把静态图片目录映射出来。解决我一般会把菜品图片统一放到后台项目的static/upload/目录并保证 Nginx 或 Spring Boot 静态资源映射能访问http://域名/upload/xxx.jpg。在小程序端拼图片地址时要确保协议和域名一致不能用http://localhost拼给真机访问。上传代码里后端保存文件名应该用UUID 原扩展名避免中文名和重名覆盖。前端如果使用wx.uploadFile注意formData里要带上 token否则后台鉴权过不去。图片上传后返回的路径最好直接存完整 URL减少前端拼接时的报错概率。如果你改完仍然不显示用浏览器直接访问那个图片 URL看是 404 还是 403就能区分是路径问题还是权限问题。4.4 订单并发与数据库锁你以为点餐系统没有并发实际上高峰期一桌同时扫码下单或者同一个用户连续点击两次“提交订单”就会产生重复订单或超卖菜品。现象同一时刻下单订单列表出现两条相同记录或菜品库存减了两次。原因提交订单的代码没有做幂等控制也没有对库存做原子操作。有些源码在提交时先查库存再update中间有空隙。解决最简单做法是在订单表加一个业务订单号前端调用后台下单时传入一个随机生成的订单号后台插入前先查重。库存扣减语句改成-- 库存扣减的原子操作示例 UPDATE dish SET stock stock - 1 WHERE id #{dishId} AND stock 1;这条语句的精髓在AND stock 1如果影响行数为 0说明库存不足直接返回失败而不是先查库存再扣减。另外提交订单的事务要包住“插入订单表 插入明细表 扣库存”这三步任何一个失败都要回滚。后台里一般会有Transactional注解如果源码没有你要在 service 方法上补上。要记住点餐系统的库存不像电商那么严格菜品卖完可以售罄下架不建议引入分布式锁除非你已经确认同一菜品会被大量并发下单。5. 把源码变成可运营的系统上线前我必查的几个细节到这里你已经有能跑的完整点餐小程序了但离“可以开业”还差最后几步。我习惯在交付前按这个顺序检查可以帮你少走弯路。第一域名与 HTTPS。小程序的wx.request和wx.uploadFile都要求 HTTPS 域名而且需要在小程序后台配置“服务器域名”。如果没有域名可以先用 IP 测试但这只是临时方案正式运营前必须上域名并备案。第二数据库备份。点餐系统最怕丢订单。建议写一个定时任务每天凌晨用 mysqldump 导出数据库mysqldump -u root -p ordering_system --single-transaction --routines /backup/ordering-$(date %F).sql--single-transaction适合 InnoDB 表导出时不锁表餐厅营业中也能安全备份。--routines会把存储过程和函数也备份某些老系统把订单流程写在存储过程里不能漏。第三检查管理员账号和日志。很多源码自带默认管理员账号比如 admin/admin123上线前一定要改掉。后台日志级别要调到 info尤其保存支付回调日志这样出问题时能回溯参数。第四进程守护。如果后台是 Node 写的建议用 pm2 保持后台常驻不要直接关终端。常用命令pm2 start server.js --name ordering-backend pm2 save pm2 startuppm2 save保存进程列表pm2 startup设置开机自启。这一步容易被忽略但真正部署时要靠它避免服务中断。最后一件事是给自己留一个“后悔药”在改动数据库前先把原 SQL 备份一份。我一开始部署这类源码时吃了不少亏不是 MySQL 密码对不上就是 BASE_URL 忘了改。后来总结出一个习惯每拿到一套源码先把配置文件里所有带 localhost 和 123456 的占位值列出来逐项改成自己的环境再启动服务。这个习惯帮我省了很多排查时间。希望这份点餐小程序的落地笔记也能帮你少踩几个坑。本文还有配套的精品资源点击获取