简介金味智能餐厅点餐支付管理系统 v5.0.715 是一套面向现代餐饮企业的 Web 化点餐支付解决方案主要服务于餐厅管理者、店员以及 PHP 开发学习者用于解决顾客扫码点餐、订单管理、移动支付与后台数据维护等日常运营问题。资源包共 106 个文件以 26 个 PHP 程序文件为功能核心辅以 46 张 JPG 界面图片、16 个 MP3 音频可用于语音提示或演示、5 个 XML 配置及安装说明、快捷链接等压缩包整体仅 1.66MB目录区分 client、server、member结构清晰便于检索。系统实现二维码扫码点餐、微信/支付宝自动接口与扫码支付、订单打印控件等功能并包含安装脚本和帮助文档可快速搭建体验完整流程。通过学习源码开发者能掌握 PHP 点餐系统前后端交互、支付对接、文件目录组织及常见配置方法。已有 221 人学习下载适合具备基础 PHP 知识、希望了解餐饮管理系统实现细节的开发者。1. 金味智能餐厅点餐支付管理系统 v5.0.715这个版本号背后的实战分量餐厅点餐收银系统真正决定体验的不是扫码瞬间的“滴”一声而是网络断了、厨打机卡纸、支付回调迟到三秒时门店还能不能把这顿饭顺利收尾。金味智能餐厅点餐支付管理系统 v5.0.715 是已经跑过多家门店、完成多轮迭代的成熟版本不是毕业设计级的小程序套壳。它覆盖开台点菜、厨打联动、聚合支付、会员储值、营业报表六条主线能独立撑起一家小型连锁餐饮的日常运转。这篇笔记适合两类人一类是准备给自家门店选型部署的经营者另一类是接手这类项目做二次开发或维护的工程师。我会按“模块拆解 → 部署初始化 → 核心参数 → 踩坑实录”的顺序把能直接抄走的配置和命令铺开来讲。2. 拆解金味v5.0.715核心模块与三个关键选型2.1 点餐链路桌台状态机与菜品档案是系统的骨架做餐厅系统第一件事不是写支付而是先把桌台状态和菜品档案建对。金味这套 v5.0.715 的点餐模块核心是一个桌台状态机空闲、已开台、已点菜、待结账、已清台五个状态来回切换。桌台状态不对后面所有环节都会错——最常见的就是“客人还没走系统里桌台已被清掉单子直接丢单”。菜品档案的设计要区分三类普通菜、套餐菜、称重菜。称重菜在点菜端要弹重量输入框套餐菜要能拆成子项进厨打分组。我的建议是新增菜品时把这三个基础属性先定死宁可多花十分钟设置也不要上线后再补。# 菜品档案初始化参考字段 (pseudo) dish { dish_id: D10023, name: 酸菜鱼, category: 热菜, # 用于厨打分组 type: normal, # normal / combo / weighted price_mode: fixed, # fixed 固定价, weighted 称重 sell_status: on_sale, # on_sale / sold_out / hidden print_group: kitchen_1, # 对应后厨打印机分组 stock_enabled: True, # 是否启用库存扣减 stock: 50, }这段配置的逻辑在于print_group直接决定了这道菜出现在哪个后厨打印机上stock_enabled决定是否参与中央库存扣减。很多门店为了省事把库存关了短期没事一旦遇上海鲜、日售完菜品就会出现“系统显示有货、后厨却说没了”的矛盾。2.2 支付模块为什么要抽象一层多通道与回调v5.0.715 的支付模块并不是直接对接微信支付官方接口而是封装了一个支付网关层。这一层网关负责统一处理微信、支付宝、银联、会员余额四类支付通道。这样设计的理由很实际门店的收款通道经常轮换尤其是聚合收款码渠道费谈判、通道切换的时候如果业务代码里直接耦合某个支付SDK换通道就要改一堆业务代码。网关层的核心接口只有四个创建支付、查询支付、撤销支付、退款。所有通道都实现同一套接口。# 统一支付接口抽象 (python) class PaymentGateway(ABC): abstractmethod def create_payment(self, order_no: str, amount: int, channel: str, **kwargs) - dict: 创建支付单 order_no: 业务订单号, 必须是门店内唯一 amount: 金额, 单位分, 避免浮点误差 channel: wechat / alipay / unionpay / balance 返回: {transaction_id, cashier_url, raw_result} abstractmethod def query_payment(self, order_no: str, channel: str) - dict: 主动查单, 用于回调丢失后的兜底 abstractmethod def cancel_payment(self, order_no: str, channel: str) - bool: 撤销未支付订单 abstractmethod def refund(self, order_no: str, refund_no: str, amount: int) - dict: 退款, refund_no 必须唯一, 用于对账这里有一个我在多个项目里反复强调的点金额单位必须用分来存。用浮点数存金额日积月累会出现0.01元的误差而财务报表要求分毫不差——这不是玄学是钱算错之后的血泪教训。2.3 会员与营销储值、积分、折扣的边界会员模块在 v5.0.715 中默认包含储值卡、积分、优惠券、会员价四类能力。但四类权益必须明确叠加顺序否则就会出现“折上折”把客单价打到负数。业内常用的叠加规则是计算出订单原价先按会员价替换菜品价格再判断是否满足优惠券门槛最后抵扣储值余额。折扣码与会员价互斥不能同时生效。# 订单优惠计算顺序 (伪代码) def calc_order_final_amount(order_items, member_level, coupon): total sum(item.price for item in order_items) # 第一步: 会员价替换 for item in order_items: member_price get_member_price(item.dish_id, member_level) if member_price and member_price item.price: item.price member_price # 第二步: 优惠券抵扣 if coupon and total coupon.min_amount: total - coupon.amount # 第三步: 储值余额支付 final_amount max(total, 0) # 注意: 储值余额只能支付最终金额, 不能参与折扣计算 return final_amount这个顺序一旦错了财报上的“客单价”“折扣率”指标就全乱了。我见过一个门店的报表毛利率突然掉了八个点最后排查发现是储值赠送金额被当成了营业收入计入而不是作为营销费用单独列支——这就是权益边界没定清楚的典型。2.4 数据底座与选型理由MySQL、Redis与消息队列v5.0.715 的数据层用的是经典组合MySQL 存业务主数据Redis 做缓存和分布式锁RabbitMQ 处理订单变更为核心的异步事件。这套组合不新潮但在餐饮场景下足够稳定。MySQL 主要负责订单表、订单明细表、支付流水表、菜品表、门店表。订单表与明细表必须分开订单只存总额和状态明细存每道菜的数量和单价。这样做的好处是报表统计时不需要解析 JSON直接用 SQL 聚合即可。Redis 的用途有三个一是缓存菜品列表减轻点餐端的高频查询压力二是做桌台状态的分布式锁防止并发开台三是做支付回调的幂等判断。分布式锁和幂等判断这两块在下文部署和避坑中会细讲。RabbitMQ 主要承担三个事件订单创建后通知厨打服务、支付成功后通知会员积分服务、退款后通知库存回补。用消息队列把同步调用拆成异步好处是支付高峰期后厨打印机不会因为并发导致漏单。3. 部署与初始化从空数据库到可开台点菜3.1 部署方式与最低硬件要求金味 v5.0.715 提供两种部署方式单机一体包和 Docker Compose 模式。单机一体包适合单店Docker Compose 适合多门店或者需要横向扩容的场景。先说硬件预算。单店规模20桌以内一台4核8G的服务器足够存储建议SSD操作系统优先选 Rocky Linux 9 或 Ubuntu 22.04。需要注意的是v5.0.715 对低版本 CentOS 7 支持有限部分依赖如 MySQL 8.0 的认证插件在 CentOS 7 上会有兼容问题别在旧系统上浪费时间。# Docker Compose 部署参考 (bash) # 目录结构 # /opt/jinwei # ├── docker-compose.yml # ├── mysql/init/ # └── app/conf/ cd /opt/jinwei docker compose up -d mysql redis rabbitmq sleep 20 # 初始化数据库 docker exec -i jinwei-mysql mysql -uroot -p${DB_PASSWORD} /opt/jinwei/mysql/init/schema_v5.0.715.sql # 启动应用服务 docker compose up -d app gateway print-server docker compose ps参数说明schema_v5.0.715.sql是系统的初始化建表脚本包含表结构、初始菜单数据、默认管理员账号。print-server是独立部署的厨打服务必须和主应用分开启动这样厨打机挂掉不会连带点餐服务崩溃。3.2 初始化门店、桌台与菜品的几个脚本数据库装好后第一步不是急着配支付而是初始化组织架构和基础档案门店 → 区域 → 桌台 → 菜品。金味系统支持按区域管理桌台比如“大厅”“包间A”“包间B”。桌台编码必须唯一编码规则建议用两位区域号两位桌号比如01_03表示大厅3号桌。-- 初始化桌台数据 (sql) INSERT INTO t_restaurant_table (table_code, table_name, area_id, seat_cnt, table_status) VALUES (01_01, 大厅1号, area_001, 4, idle), (01_02, 大厅2号, area_001, 6, idle), (02_01, 包间A1, area_002, 10, idle); -- 注: table_status idle | occupied | settle | cleaning -- 状态切换只允许通过后台接口完成, 不允许直接改库这里要强调桌台状态不要通过数据库直接修改必须走服务端接口。直接改库会出现“内存中桌台状态与数据库不一致”的问题导致重复开台。正确的做法是改完接口后观察 Redis 缓存是否同步更新。菜品初始化用 Excel 导入更高效。金味系统后台支持菜品批量导入模板模板字段包括菜品名称、分类、价格、估清库存、厨打分组。导入前先校验模板里不能有空行和重复的菜品编码否则会静默跳过而不是报错造成“部分上架成功”的错觉。3.3 支付通道配置参数与联调清单支付配置是整个初始化中最容易出状况的环节。这里不区分具体支付服务商只说通用参数清单和常见名称你拿到商户号后对着配即可。# 支付网关配置文件 conf/payment.yaml 关键参数 (yaml) payment: channel_wechat: enabled: true app_id: wx_xxxxxxxx # 服务号或小程序AppID mch_id: 16xxxxxxxx # 商户号 api_key: xxxxxxxxxxxxxxxx # APIv3密钥 cert_path: /certs/wx_apiclient.pem notify_url: https://api.yourdomian.com/pay/notify channel_alipay: enabled: true gateway: https://openapi.alipay.com/gateway.do app_id: 2025xxxxxxxx private_key_path: /certs/alipay_private_key.pem alipay_public_key_path: /certs/alipay_public_key.pem notify_url: https://api.yourdomian.com/pay/notify参数说明notify_url必须是公网可访问的HTTPS地址且不能带查询参数。支付服务商回调只认HTTPS这一点是硬性要求。联调时我建议按这个顺序自测点菜生成订单调起支付商户端是否弹出收银台完成支付等待异步回调后台是否自动标记已支付手动模拟回调超时在支付网关后台点“查单”系统是否能主动拉到支付结果发起退款确认原路返回和系统状态同步3.4 餐厨联动厨打分组与打印模板配置餐厨联动是金味系统的亮点也是最容易翻车的地方。配置的核心是“厨打分组”把菜品分到不同的厨房档口比如凉菜间、热菜房、主食档。每个档口独立分配一台打印机避免热菜单打到了凉菜间。厨打参数有两个值经常被人忽略print_count和pre-print。print_count可以设置同一道菜打印联数次重菜多的门店建议设为1避免后厨打单机一片白纸海。pre-print是预先打印适合烤鸭、牛排这类需要提前准备的菜品可以在下单时直接打单到对应档口。# 厨打服务配置参考 (bash) { printer_groups: [ { group_id: kitchen_1, name: 热菜房, printer_ip: 192.168.1.100, printer_port: 9100, # 默认9100, 部分热敏打印机是9100 paper_width: 80mm, template: order_dish_thermal.jrxml } ], reprint_on_failure: true # 打印失败自动重发 }厨打机切忌用云打印方案本地局域网直连打印机延迟更低、稳定性更高。门店网络抖动时云打印会积压任务而且不易排查。4. 核心流程配置点单、支付、会员与统计的硬参数4.1 开台点菜与加菜流程的参数模板开台点菜涉及的核心参数是“未结账状态下是否允许加菜减菜”以及“整单折扣是折前还是折后”。我建议两套都保持默认专业模式开台后任意菜品可加但减菜必须在后厨未打印前才能操作已经出厨打单的菜减菜只能走退菜审核流程。这套规则可以防止服务员误删已制作菜品的单子也避免后厨做了菜却因“减菜”拿不到钱。# 开台点菜流程核心逻辑 (python伪代码) def create_order(table_id, dishes): # 1. 锁表, 防止并发开台 with redis_lock(ftable:{table_id}): table get_table(table_id) if table.status ! idle: raise BizError(桌台已被占用) # 2. 创建订单头 order create_order_header(table_id) # 3. 逐项验菜品状态和库存 for d in dishes: if d.sell_status ! on_sale: raise BizError(f菜品 {d.name} 已下架) if d.stock_enabled and d.stock 0: raise BizError(f菜品 {d.name} 已售罄) # 4. 写入订单明细并扣减库存 batch_write_order_items(order, dishes) batch_deduct_stock(dishes) # 5. 发布厨打消息 publish_kitchen_event(order.id, group_by_food(dishes)) return order这一段写出来是说明整套链路的顺序。特别要注意的是第5步厨打事件不能在第4步之前发。先扣库存再出单如果出单失败可以退单回补库存先出单后扣库存单子出了但库存扣了一半对账时很难查。4.2 支付回调与幂等这行代码不能省支付回调是异步的意味着同一个支付结果可能被推送多次也可能延迟推送。如果你的回调处理逻辑不幂等顾客支付成功后系统弹了两次“支付成功”的提示单纯是体验问题更糟的是积分和储值赠送被触发两次财报全乱。幂等的最终方案是拿“支付流水号”做唯一约束支付流水号建议用支付通道渠道交易号复合拼接因为支付通道的交易号在全局是唯一的但更换过支付渠道后可能重复。# 支付回调处理 (python) def handle_payment_callback(parsed_body): # 支付流水号 通道 渠道交易号 biz_no f{parsed_body.channel}:{parsed_body.transaction_id} lock_key fpay_lock:{biz_no} if not redis.set(lock_key, 1, nxTrue, ex30): return {code: OK} # 重复回调, 直接返回, 不重复处理 # 校验金额: 数据库订单金额 与 回调金额必须一致 order fetch_order(parsed_body.order_no) if order is None or order.amount ! int(parsed_body.amount): alert_error(f订单金额不匹配: {parsed_body.order_no}) return {code: FAIL} if order.status in (PAID, FINISHED): return {code: OK} # 事务: 更新订单状态 写入支付流水 赠送积分 with db.transaction(): update_order_status(order.id, PAID) insert_payment_flow(order.id, biz_no, parsed_body.amount) grant_points(order.id) # 发送消息, 通知厨打/排号等下游 publish_order_paid_event(order.id) return {code: OK}代码里还藏了一个容易被忽视的点order.amount ! int(parsed_body.amount)这次校验如果回调金额小于应付金额直接告警而不是通过。这是防止“支付金额被篡改”的护城河。有些系统为了用户体验友好给支付金额不一致留了缓冲结果被刷单这就是黑匣子里的教训。4.3 会员储值与结算的联动规则储值规则往往牵扯到“赠送金额是否可退”的问题。金味系统默认支持两套储值模式固定赠送和规则赠送。固定赠送就是充100送10规则赠送支持按阶梯自动匹配比如充200送30、充500送80。按我的经验储值金额与赠送金额必须分开记录结算和退款时才不至于算错。客人退卡时如果只退本金、不退赠送系统要能自动计算应退金额。# 储值账户余额扣除逻辑 (python) def deduct_balance(member_id, amount): # 使用行级锁, 防并发扣减 row db.execute( SELECT id, balance, gift_balance FROM member_account WHERE member_id %s FOR UPDATE, member_id ) available row.balance row.gift_balance # 可扣总余额 if available amount: raise BizError(余额不足) # 优先扣赠送金额, 再扣本金 deduct_gift min(row.gift_balance, amount) deduct_principal amount - deduct_gift db.execute( UPDATE member_account SET gift_balance gift_balance - %s, balance balance - %s WHERE member_id %s, deduct_gift, deduct_principal, member_id ) # 每笔扣款写入流水: member_balance_log为什么优先扣赠送金额因为赠送金额在财务上是营销费用优先消耗营销费用可以让账面上的现金本金保留更久这对门店现金流有帮助。这个细节不一定写在系统文档里但我是强烈建议保留这个默认规则。4.4 营业日报的关键口径与对账逻辑营业日报是老板每天必看的页面但很多系统的报表口径算得模棱两可。v5.0.715 里比较可靠的统计维度是营业额 已支付订单的实收金额合计不含退款实收金额 菜金 服务费 - 折扣 - 优惠券抵扣客单价 实收金额 ÷ 有效订单数订单金额大于0折扣力度 优惠金额 ÷ 原价金额这里有一个报表“骗人”的坑如果把“未支付订单的整单金额”也计入营业额报表虚高但实际到账很少门店老板会误判经营状况。按实际支付口径统计虽然数据曲线忽高忽低但更真实。-- 日经营报表查询核心SQL (sql) SELECT DATE(pay_time) AS biz_date, SUM(CASE WHEN pay_status SUCCESS AND refund_status IS NULL THEN order_amount ELSE 0 END) AS gross_sales, SUM(CASE WHEN pay_status SUCCESS AND refund_status IS NULL THEN amount_received ELSE 0 END) AS actual_sales, COUNT(DISTINCT CASE WHEN pay_status SUCCESS AND refund_status IS NULL THEN order_id END) AS valid_orders FROM t_payment WHERE pay_time 2025-01-01 00:00:00 AND pay_time 2025-01-02 00:00:00 GROUP BY DATE(pay_time);很多对账不平根源在于部分订单当天支付成功、次日才退款按日级统计就会出现单日数据反弹。对账时建议把“当日实付”和“累计未退”分开统计并保留订单与支付流水的一对多关系记录退完款的订单在详情页要能看到原始支付记录。5. 避坑指南五个我在餐厅系统里踩过的坑5.1 支付回调丢失顾客已付款但订单显示未支付现象门店前台发现一单已经支付成功但点餐系统上仍显示“待支付”客人也收到了扣款短信前台只能手工标记结账晚上对账时这笔钱在平台上“凭空消失”。原因支付回调网络不是100%可靠回调可能延迟或丢失。系统如果只依赖被动回调没有主动查单兜底回调一旦丢了就一直停留在未支付状态。解决在订单创建15分钟后增加一个定时任务轮询未支付订单主动向支付网关调用查询接口。金味系统在“挂单任务管理”中可以设置查单间隔。我通常建议设置为 5分钟、15分钟、30分钟三个时间节点各查一次如果三次都确认未支付允许自动关闭订单。5.2 厨打机乱码与串单后厨一个劲催菜现象厨打机出单时带有乱码字符甚至把A桌的菜单打到B桌的打印机上后厨出菜错乱。原因两处——一是打印编码没统一菜名里有生僻字或特殊符号时用了不同编码二是厨打机IP配错热菜房打印机配置了凉菜间的IP。解决厨打模板统一使用UTF-8编码下发前先打印一张测试页确认无乱码。同时厨打IP应在网络层面做绑定不要使用DHCP动态分配——IP一旦轮换系统还是按照旧IP打印单子就飞到别人家了。这是一个非常隐蔽的坑我在两个门店都栽过后来强制规定打印机必须静态IP并抄录在案。5.3 菜品显示售罄却仍可下单现象海鲜池里售罄的鱼显示“估清”但客人下单操作仍然放行后厨接单后只能电话告知卖完。原因门店使用了“多点位点餐”——比如服务员PDA和后厨大屏是两个入口两个入口读的是不同缓存。售罄状态只更新了后厨大屏的缓存PDA缓存没有同步刷新。解决售罄状态必须走统一库存服务而不是直接改本地缓存。操作上在“菜品档案”里开启“全局库存扣减”这样任意端口下单都会先检查中央库存。切忌图省事在多个点餐端本地各自维护一份菜品列表。5.4 会员余额莫名变成负数现象顾客在门店消费时被告知“余额不足”但客人坚称刚充过值后台一查账户余额确实是负数。原因储值扣款时没有加行锁或乐观锁请求并发量稍大时两个请求同时读到扣款前余额一起扣款就超扣了。尤其是“扫码点餐收银台同时结算”的场景容易触发。解决扣款时使用SELECT ... FOR UPDATE行锁同时给会员账户表增加“版本号”字段每次扣款时校验版本号。金味系统在 v5.0.715 版本中默认启用了行锁但如果你改动过代码需要确认锁没有被去掉。如果再出问题打开“余额操作日志”每一笔扣减的来源请求ID必须能对上。5.5 日结报表数字对不上现象店长投诉昨天营收是五万二财务系统算出来是四万九两个数字差了三千块而且每天差的金额都不一样。原因报表模块统计了“下单时间”的数据而财务模块用的是“支付时间”。客人跨日买单或者定金单次日付尾款时两类统计在边界日产生了偏差。解决统计口径必须唯一。建议以“支付时间”作为营业日结的基准下单时间只用于效率分析。然后在报表页给两个口径加开关默认展示“支付时间口径”。我习惯在每个月初做一次人工抽查取上月某三天的支付流水与报表数字手工Excel透视比对确认无误后再开展门店经营分析。6. 进阶用日志与状态机把餐厅系统调到“不用人盯”6.1 给每个接口加链路ID餐厅系统的排障难点在于节点多小程序端、收银台、API服务、厨打服务、支付网关一个订单流转五六个组件。没有链路ID出了问题只能挨个系统翻日志效率极低。v5.0.715 支持请求头透传链路ID建议从入口在HTTP请求中生成trace_id后续所有内部调用都在日志中携带这样在ELK或Loki里过滤一个ID就能看到完整调用链。# 链路日志埋点示意 (python) import uuid import logging def pre_request_hook(): trace_id uuid.uuid4().hex logging.info(request_start, extra{trace_id: trace_id}) # 传给下游厨打/支付时, 在请求头带上 trace_id requests.post( printer_service_url, headers{X-Trace-Id: trace_id} )6.2 把订单状态机做成可视化面板“待支付→已支付→制作中→已上菜/已退菜→已结账”这条链路系统里都有但状态流转的异常往往藏在细节里。我习惯在维护脚本里加一道巡检任务每小时扫描一次状态卡住的订单——比如“已支付”超过30分钟仍然没有进入“制作中”的订单直接推送告警到工作群。这套按状态机巡检的机制比靠消费者投诉发现快得多。金味后台自带“订单状态图”功能但它按天出报告对实时异常有点慢。如果你有一定的开发能力可以写一段脚本每分钟轮询一次待处理订单状态把异常项推送到钉钉或企微机器人。6.3 菜品估清与售罄预警联动估清不只是“卖完”这一个动作你可以把它做成经营预警。比如设置警戒线某菜品当日销量达到库存的80%时自动推送通知给店长提示准备追加备货或调整每日估清量。这个功能不需要大改只需要在库存扣减逻辑里加一个阈值判断一旦触发就向企业微信机器人推送一条消息。看起来是个很小的功能实测算下来能有效减少因为“突然卖完”而导致的客诉。做到这一步才能说这套系统真正“偷懒”成功了——不是靠人整天盯屏而是靠状态机和日志让系统自己报信。这几年折腾下来我最大的教训就是一开始别贪图功能多先把“发了消息确认有人接”“支付状态随时能查”这类基础打牢。后厨不催菜、财务不对账、客人不问“我到底付没付”这套系统就算立住了。希望这篇笔记能帮你把金味v5.0.715稳稳接住少走几个我走过的弯路。本文还有配套的精品资源点击获取