简介这份资源是面向本地外卖商家与小程序开发者的霸王餐系统源码围绕美团、饿了么等主流外卖场景提供商家入驻、霸王餐发布、优惠券设置与用户评价反馈等核心模块帮助商家以免费体验活动吸引新客、沉淀口碑也为想切入本地生活服务领域的开发者提供一套可参考的完整实现思路。压缩包为zip格式整体约2.06MB文件列表以bawangcan命名主要包含程序源代码与配套数据文件分别承载用户界面、商家管理、霸王餐发布兑换及评论系统等逻辑以及商家、用户、活动与消费记录等数据存储。目前已有1795人浏览学习适合具备一定小程序开发基础、希望研究外卖营销系统架构或进行二次开发的技术人员参考可从中了解霸王餐活动的业务流程设计、模块划分与数据组织方式。1. 省钱兄外卖霸王餐程序从零跑通一套外卖优惠券小程序有个做本地生活的朋友找我说想搞个外卖霸王餐的小程序让用户领券下单后返现问我有没有现成的轮子。我翻了一圈找到了这套「省钱兄外卖霸王餐程序」。它的定位很直接对接美团、饿了么的联盟推广接口用户在小程序里领优惠券、跳转下单平台拿到佣金后再以霸王餐或返现的形式返还给用户。说白了就是一套 CPS 分销 返利系统核心链路是「领券 → 跳转 → 下单 → 回调 → 返现」。适合谁想切入本地生活赛道的个人开发者、做私域流量的运营团队以及需要一套外卖 CPS 中台做二次开发的技术同学。整套源码前后端齐全小程序端 管理后台 服务端拿到手就能部署跑起来。2. 技术栈与目录结构拿到源码先看什么2.1 前后端技术选型拆解这套程序的架构是典型的小程序 服务端 管理后台三段式。小程序端用的是原生微信小程序框架没有上 uni-app 或 Taro 这类跨端方案好处是包体积小、调用微信原生 API 没有中间层损耗坏处是只能跑在微信生态里。服务端我看到的常见做法是 Node.js Express 或者 PHP ThinkPHP具体取决于你拿到的版本分支。数据库用 MySQL 存用户、订单、返现记录Redis 做会话缓存和接口限流。管理后台一般是 Vue Element UI 或者 React Ant Design用来配置返现比例、审核提现、查看佣金报表。这里有个点要注意外卖 CPS 的核心不是前端长什么样而是服务端怎么处理联盟平台的回调。美团联盟和饿了么联盟的订单回调都是异步的而且有签名校验服务端必须能正确处理重复回调、延迟回调、退款回调这三种情况。我见过太多人前端做得漂漂亮亮结果回调没处理好用户下了单没返现客诉直接爆炸。2.2 目录结构逐层说明拿到源码后我一般先看根目录的层级划分这能快速判断项目的工程化程度。典型的目录结构长这样project-root/ ├── miniprogram/ # 微信小程序端 │ ├── pages/ # 页面目录 │ │ ├── index/ # 首页-优惠券列表 │ │ ├── order/ # 订单页-跳转下单 │ │ ├── mine/ # 个人中心-返现记录 │ │ └── withdraw/ # 提现页 │ ├── utils/ # 工具函数 │ │ ├── request.js # 请求封装 │ │ └── auth.js # 登录鉴权 │ └── app.js # 小程序入口 ├── server/ # 服务端 │ ├── controllers/ # 控制器 │ │ ├── coupon.js # 优惠券相关 │ │ ├── order.js # 订单与回调 │ │ └── user.js # 用户与返现 │ ├── models/ # 数据模型 │ ├── routes/ # 路由定义 │ ├── middlewares/ # 中间件-鉴权/日志 │ └── config/ # 配置文件 ├── admin/ # 管理后台 │ ├── src/ │ │ ├── views/ # 页面 │ │ └── api/ # 接口封装 │ └── package.json └── docs/ # 部署文档与接口说明这个结构不算复杂但有几个地方值得留意。server/controllers/order.js是整个项目最核心的文件联盟回调、订单状态机、返现计算都在这里。miniprogram/utils/request.js封装了统一的请求拦截和 token 刷新逻辑二次开发时改接口地址就找这个文件。server/config/下面一般会有db.js、redis.js、platform.js三个配置platform.js里放的是美团和饿了么的 appKey、appSecret、回调地址部署前必须改。2.3 数据库表设计要点数据库这块核心表就那么几张但字段设计直接决定了后续能不能扩展。我拿到的版本里关键表包括表名用途关键字段users用户信息openid, unionid, balance, total_commissioncoupons优惠券池platform, activity_id, title, commission_rateorders订单记录order_sn, user_id, platform, status, commissionwithdrawals提现申请user_id, amount, status, audit_timecallbacks回调日志raw_data, platform, order_sn, processedorders表的status字段是状态机的核心一般有pending已下单待确认、confirmed联盟已确认、settled佣金已结算、refunded已退款、invalid无效订单这几个状态。返现逻辑就是监听状态流转从confirmed到settled时给用户加余额。callbacks表很多人会忽略但我强烈建议保留因为联盟回调出问题的时候这张表就是唯一的黑匣子能帮你快速定位是没收到回调还是处理逻辑有 bug。3. 本地跑通从环境准备到小程序预览3.1 服务端启动与配置修改先把服务端跑起来这是整个链路的基础。假设你拿到的是 Node.js 版本步骤大致如下# 进入服务端目录 cd server # 安装依赖 npm install # 复制配置文件模板 cp config/config.example.js config/config.js # 编辑配置文件填入数据库和联盟平台信息 vim config/config.js配置文件里必须改的几个地方// config/config.js 关键配置项 module.exports { db: { host: 127.0.0.1, // 数据库地址 user: root, // 数据库用户名 password: your_pwd, // 数据库密码 database: takeout_cps // 数据库名 }, redis: { host: 127.0.0.1, port: 6379, password: // Redis 密码没有就留空 }, platform: { meituan: { appKey: 你的美团联盟appKey, appSecret: 你的美团联盟appSecret, callbackUrl: https://你的域名/api/callback/meituan }, eleme: { appKey: 你的饿了么联盟appKey, appSecret: 你的饿了么联盟appSecret, callbackUrl: https://你的域名/api/callback/eleme } }, jwtSecret: 自定义一个随机字符串, // token 签名密钥 commissionRate: 0.7 // 默认返现比例70% 佣金返给用户 }callbackUrl必须是公网可访问的 HTTPS 地址本地开发时可以用内网穿透工具临时映射一个域名出来但上线前一定要换成正式域名。commissionRate是平台抽成后返给用户的比例这个值直接影响用户留存一般设在 0.6 到 0.8 之间太低用户没动力太高平台不赚钱。数据库初始化# 创建数据库 mysql -u root -p -e CREATE DATABASE takeout_cps DEFAULT CHARSET utf8mb4; # 导入表结构 mysql -u root -p takeout_cps docs/schema.sql # 导入初始数据优惠券模板、管理员账号等 mysql -u root -p takeout_cps docs/init_data.sql启动服务# 开发模式启动带热重载 npm run dev # 生产模式 npm start服务跑起来后访问http://localhost:3000/api/health应该返回{status:ok}。如果报数据库连接错误检查config.js里的密码和数据库名如果报 Redis 连接失败确认 Redis 服务已启动或者临时把 Redis 相关逻辑注释掉先跑通主流程。3.2 小程序端配置与预览小程序端用微信开发者工具打开miniprogram/目录。打开之前先改两个地方// miniprogram/utils/request.js const BASE_URL http://localhost:3000/api; // 改成你的服务端地址 // miniprogram/app.js App({ globalData: { userInfo: null, token: null, baseUrl: http://localhost:3000/api } })开发阶段可以在微信开发者工具里勾选「不校验合法域名」这样localhost也能请求通。但真机预览和上线时必须用 HTTPS 域名而且要在微信公众平台配置request合法域名。小程序端的核心页面逻辑在pages/index/index.js它做了三件事拉取优惠券列表、渲染成卡片、点击后跳转联盟链接。跳转逻辑值得看一下// pages/index/index.js 优惠券点击跳转 onCouponTap(e) { const coupon e.currentTarget.dataset.coupon; // 先请求服务端生成推广链接 wx.request({ url: ${app.globalData.baseUrl}/coupon/generate, method: POST, data: { couponId: coupon.id, userId: app.globalData.userInfo.id }, success: (res) { if (res.data.code 0) { // 拿到带推广参数的链接跳转 wx.navigateTo({ url: /pages/order/order?url${encodeURIComponent(res.data.data.url)} }); } else { wx.showToast({ title: 生成链接失败, icon: none }); } } }); }这里为什么要先请求服务端生成链接而不是直接跳转因为联盟推广链接需要带上你的推广位 ID 和用户标识这些参数不能暴露在小程序前端必须在服务端拼接。服务端生成链接时会记录「哪个用户点了哪个券」后续回调回来才能对应上返现对象。这个设计是外卖 CPS 的标准做法少了这一步回调回来你不知道该返给谁。3.3 回调联调与模拟测试本地开发最麻烦的是回调联调因为联盟平台不会往你的localhost发回调。我的做法是写一个模拟回调的脚本手动触发订单状态流转// scripts/mock-callback.js 模拟联盟回调 const axios require(axios); const crypto require(crypto); // 模拟一笔美团订单回调 const mockOrder { order_sn: MT Date.now(), // 订单号 platform: meituan, status: confirmed, // 订单状态 commission: 5.80, // 佣金金额 user_id: 1, // 用户ID timestamp: Math.floor(Date.now() / 1000) }; // 生成签名和联盟平台规则一致 const secret 你的appSecret; const signStr Object.keys(mockOrder).sort().map(k ${k}${mockOrder[k]}).join() key${secret}; mockOrder.sign crypto.createHash(md5).update(signStr).digest(hex).toUpperCase(); // 发送回调 axios.post(http://localhost:3000/api/callback/meituan, mockOrder) .then(res console.log(回调结果:, res.data)) .catch(err console.error(回调失败:, err.message));跑这个脚本之前确保服务端已经启动数据库里有user_id1的用户记录。回调成功后去orders表看有没有新增记录callbacks表有没有原始数据用户的balance有没有增加。如果回调返回签名错误检查签名算法是否和联盟文档一致如果订单没入库看controllers/order.js里的处理逻辑是不是有字段映射错误。提示模拟回调脚本不要在生产环境跑会污染真实订单数据。建议在测试数据库上做联调。4. 核心模块拆解回调处理与返现计算4.1 联盟回调的签名校验与幂等处理回调处理是整个系统最容易翻车的地方。联盟平台可能会重复发送同一笔订单的回调也可能因为网络问题延迟几分钟才到。如果没做幂等用户下一单你返两次钱直接亏穿。来看核心代码// controllers/order.js 回调处理核心逻辑 const handleCallback async (req, res) { const { platform } req.params; const callbackData req.body; // 1. 记录原始回调数据方便排查 await CallbackLog.create({ platform, raw_data: JSON.stringify(callbackData), order_sn: callbackData.order_sn, created_at: new Date() }); // 2. 签名校验 const isValid verifySign(callbackData, platform); if (!isValid) { console.warn([回调] 签名校验失败: ${callbackData.order_sn}); return res.json({ code: 1, msg: sign error }); } // 3. 幂等检查同一订单同一状态只处理一次 const existOrder await Order.findOne({ where: { order_sn: callbackData.order_sn } }); if (existOrder existOrder.status callbackData.status) { console.log([回调] 重复回调已忽略: ${callbackData.order_sn}); return res.json({ code: 0, msg: duplicate }); } // 4. 状态机流转 await processOrderStatus(callbackData, existOrder); res.json({ code: 0, msg: success }); };这段代码有几个关键点。第一回调数据先落库再处理哪怕后面逻辑抛异常原始数据还在能手动补。第二签名校验必须在业务逻辑之前防止伪造回调。第三幂等检查用order_sn status做联合判断同一订单同一状态重复回调直接返回成功但不处理。第四状态流转单独抽成processOrderStatus函数方便扩展新的状态。verifySign函数的实现要根据联盟文档来美团和饿了么的签名规则不一样。常见做法是把所有参数按 key 排序拼接成key1value1key2value2的字符串末尾加上keyappSecret然后做 MD5 或 SHA256。注意有些平台要求参数值做 URL 解码后再签名有些不需要这个细节搞错了签名永远过不了。4.2 返现计算与余额更新订单状态流转到settled时触发返现。返现金额的计算逻辑// services/commission.js 返现计算 const calculateRebate (order) { // 基础佣金 const baseCommission parseFloat(order.commission); // 平台抽成比例从配置读取 const platformRate config.commissionRate; // 例如 0.7 // 用户等级加成可选 const userLevel order.user_level || 1; const levelBonus { 1: 1.0, // 普通用户无加成 2: 1.05, // 白银用户5% 加成 3: 1.10 // 黄金用户10% 加成 }; // 最终返现金额 佣金 × 平台返现比例 × 等级加成 const rebate baseCommission * platformRate * (levelBonus[userLevel] || 1.0); // 保留两位小数 return Math.round(rebate * 100) / 100; }; // 余额更新事务保证 const settleOrder async (order) { const rebate calculateRebate(order); const transaction await sequelize.transaction(); try { // 更新订单状态 await Order.update( { status: settled, rebate_amount: rebate, settled_at: new Date() }, { where: { id: order.id }, transaction } ); // 增加用户余额 await User.increment( { balance: rebate, total_commission: rebate }, { where: { id: order.user_id }, transaction } ); // 记录资金流水 await BalanceLog.create({ user_id: order.user_id, amount: rebate, type: rebate, order_sn: order.order_sn, created_at: new Date() }, { transaction }); await transaction.commit(); console.log([返现] 订单 ${order.order_sn} 返现 ${rebate} 元); } catch (err) { await transaction.rollback(); console.error([返现] 订单 ${order.order_sn} 处理失败:, err.message); throw err; } };这里用数据库事务保证「订单状态更新 余额增加 流水记录」三个操作要么全成功要么全回滚。少了事务可能出现订单状态改了但余额没加或者余额加了但流水没记对账的时候就是一笔糊涂账。BalanceLog表很多人觉得多余但用户提现的时候要核对每一笔收入来源没有流水表根本说不清。4.3 提现审核与风控拦截用户余额攒够了要提现提现模块的核心是审核和风控。审核是人工或自动判断这笔提现是否合规风控是防止刷单套现。来看提现申请的处理// controllers/withdraw.js 提现申请 const applyWithdraw async (req, res) { const { userId, amount, channel } req.body; // 1. 最低提现金额校验 if (amount config.minWithdraw) { return res.json({ code: 1, msg: 最低提现 ${config.minWithdraw} 元 }); } // 2. 余额校验 const user await User.findByPk(userId); if (user.balance amount) { return res.json({ code: 1, msg: 余额不足 }); } // 3. 风控检查同一用户短时间内频繁提现 const recentCount await Withdraw.count({ where: { user_id: userId, created_at: { [Op.gte]: new Date(Date.now() - 24 * 3600 * 1000) } } }); if (recentCount 3) { return res.json({ code: 1, msg: 今日提现次数已达上限 }); } // 4. 冻结余额创建提现单 const transaction await sequelize.transaction(); try { await User.decrement({ balance: amount }, { where: { id: userId }, transaction }); await Withdraw.create({ user_id: userId, amount, channel, status: pending, created_at: new Date() }, { transaction }); await transaction.commit(); res.json({ code: 0, msg: 提现申请已提交等待审核 }); } catch (err) { await transaction.rollback(); res.json({ code: 1, msg: 系统繁忙请稍后重试 }); } };风控这块除了提现频率还应该加订单异常检测。比如同一用户短时间内大量下单又大量退款或者同一设备登录多个账号领券这些行为大概率是刷单。常见做法是记录设备指纹和 IP在返现前做一次交叉比对异常订单标记为suspicious不自动返现转人工审核。5. 避坑与常见问题部署和联调中容易翻车的地方5.1 回调收不到或验签失败现象联盟后台显示订单已确认但你的系统里订单状态还是pending用户没收到返现。原因通常有三个一是回调地址填错了联盟往一个不存在的 URL 发请求二是服务器防火墙拦截了联盟的 IP 段三是签名算法实现和联盟文档不一致验签直接失败。解决步骤先看callbacks表有没有原始数据有数据说明回调收到了问题在验签或业务逻辑没数据说明回调根本没到检查域名解析、HTTPS 证书、防火墙规则。验签失败的话把联盟文档里的签名示例拿过来用同样的参数跑一遍你的verifySign函数对比结果。我踩过的坑是参数排序时用了默认的字符串排序但联盟要求按 ASCII 码排序大小写字母的顺序不一样导致签名一直不对。5.2 订单状态卡在 confirmed 不结算现象订单回调收到了状态也变成confirmed了但一直不变成settled用户余额不增加。原因联盟的结算回调是另一个接口和订单确认回调不是同一个。很多人只对接了订单确认回调忘了对接结算回调。另外结算回调可能有延迟联盟一般是 T1 或 T7 才发结算通知。解决检查routes/下面有没有单独的结算回调路由比如/api/callback/meituan/settle。如果没有需要补上。同时确认联盟后台的结算回调地址有没有配置。如果都配了还是不到联系联盟技术支持确认结算周期。5.3 小程序跳转联盟链接被拦截现象用户点击优惠券后小程序提示「无法打开该链接」或跳转后白屏。原因微信小程序对web-view组件有域名白名单限制联盟的推广链接域名必须在微信公众平台配置为业务域名。另外部分联盟链接是短链跳转过程中会经过多次重定向微信可能拦截。解决在微信公众平台「开发管理 → 开发设置 → 业务域名」里添加联盟的域名。如果联盟用的是短链服务联系联盟确认短链的最终域名把最终域名也加上。实在不行改成让用户复制链接到浏览器打开虽然体验差一点但能绕过小程序的域名限制。5.4 数据库连接池耗尽现象服务跑一段时间后开始报ER_CON_COUNT_ERROR: Too many connections接口全部超时。原因数据库连接池配置太小或者代码里有连接没释放。常见的是在循环里反复createConnection而不是用连接池或者事务异常时没有rollback导致连接被占用。解决检查config/db.js里的connectionLimit参数默认可能是 10高并发下不够用调到 50 到 100。然后全局搜索createConnection全部改成从连接池获取。事务代码确保catch里有rollbackfinally里释放连接。5.5 提现审核后余额没扣或重复扣现象管理员审核通过提现后用户余额没减少或者减少了两次。原因审核逻辑没有用事务或者状态判断有并发问题。两个管理员同时点审核都判断status pending通过然后各自执行扣款导致重复扣。解决审核接口加行锁用SELECT ... FOR UPDATE锁住提现记录判断状态后再更新。或者用乐观锁更新时加WHERE status pending条件根据affectedRows判断是否更新成功。代码示例// 乐观锁方式更新提现状态 const [affectedRows] await Withdraw.update( { status: approved, audit_time: new Date() }, { where: { id: withdrawId, status: pending } } ); if (affectedRows 0) { return res.json({ code: 1, msg: 该提现单已被处理 }); } // 继续扣款逻辑6. 二次开发从能跑到好用的改造思路这套源码跑通之后真正要上线运营还有几个地方值得改。我拿到的版本功能是完整的但细节上偏「能用」而不是「好用」下面说几个我实际改过的点。第一个是优惠券列表的排序和筛选。原版是按数据库默认顺序返回用户看到的券没有优先级。我加了一个sort_weight字段运营在后台可以给券设置权重服务端查询时按sort_weight DESC, commission_rate DESC排序把高佣金、高转化的券排在前面。同时加了平台筛选美团/饿了么和品类筛选美食/商超/甜品用户找券效率明显提升。第二个是返现到账通知。原版返现后没有任何通知用户不知道钱到了。我接了微信订阅消息在settleOrder成功后发送一条「返现到账通知」模板 ID 在微信公众平台申请。代码大概长这样// services/notify.js 返现到账通知 const sendRebateNotify async (userId, amount, orderSn) { const user await User.findByPk(userId); if (!user || !user.openid) return; try { await wxSubscribeMessage.send({ touser: user.openid, template_id: config.wx.rebateTemplateId, page: pages/mine/mine, data: { thing1: { value: 外卖返现 }, amount2: { value: ${amount}元 }, time3: { value: new Date().toLocaleString() }, character_string4: { value: orderSn } } }); } catch (err) { console.error(返现通知发送失败:, err.message); } };第三个是佣金报表。管理后台原版只有一个总佣金数字运营想看每天、每个平台、每个用户的佣金分布得自己写 SQL。我在admin/src/views/下加了一个report/目录用 ECharts 画了趋势图和饼图服务端加了/api/admin/report/daily和/api/admin/report/platform两个接口按日期和平台聚合orders表的commission字段。这个改动不大但运营同学反馈很实用。第四个是防刷单。原版没有风控我加了一个简单的规则引擎同一openid一天内下单超过 5 笔或者同一 IP 注册超过 3 个账号订单标记为suspicious不自动返现进人工审核队列。规则配置放在config/risk.js里运营可以自己调阈值。验证改造是否生效我一般走一遍完整链路新用户注册 → 领券 → 跳转下单 → 模拟回调 → 检查返现 → 提现申请 → 审核通过 → 余额扣减。每一步都看数据库和日志确保没有遗漏。特别是回调那一步我会故意发两次同样的回调确认幂等生效不会重复返现。从那以后我每次拿到一套 CPS 类源码都强制先跑一遍「回调 → 返现 → 提现」的完整链路再去看前端页面。因为前端再好看钱算错了就是事故。希望这套思路能帮到你少走点弯路。本文还有配套的精品资源点击获取